Page 7 of 20

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Thu Jan 10, 2019 07:26
by h-v-smacker
orwell wrote:In this scheme, I omitted all of your lines, because I don't know what your plans with those are. But right, the Oasis track is missing, but that would belong to Smacker too (extension of SM1)
I could assist you if you should plan to operate your lines with interlocking too.
I built the mainline only to Personhood. What's farther oop North isn't "my" in any capacity.

Also I'd like to point out that the system notably lacks East-West mainlines. With few exceptions, we mostly have North-South tracks, and some diagonal chords. Which means that to get from one peripheral location to another, people would likely have to take a train through the center of the map and then change to another. Also it creates sort of a choke-point cluster in the center.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Thu Jan 10, 2019 07:42
by orwell
Oh, then I misunderstood this. In this case, we'll probably extend E1 up there.
And yes, the inexistence of east-west mainlines is a long-persisting problem on the server. However, there are no interesting places yet right west of spawn, so we don't need them yet.

And has anyone else noticed that Euler Street is almost totally useless?

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Thu Jan 10, 2019 13:52
by gpcf
Orwell, I dislike you unilaterally declaring a network plan. That's what the Linuxworks Dept. of planning ( https://bugs.linux-forks.de/planning/ ) is for, so players can discuss the proposals.

Euler street is meant to serve trains to Melinka, Shanielle Park and Garden of Eden.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Thu Jan 10, 2019 22:26
by orwell
I`m sorry that this has led to misunderstandings. This plan reflects my personal opinion, and I didn`t mean to enforce my opinion on you. As I wrote Och_Noe today by e-mail, I put this in here for you to discuss, and not to "declare" it. I should have clarified this in the post. Sorry for that.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Mon Jan 21, 2019 23:45
by orwell
Advtrains update
We have just successfully updated the server to the "tss" branch of Advanced Trains mod. (after 3 hours of bug-fixing and workarounding). If you operate any railway lines on the server, please read this:
- The coupling of trains now works like it should and is no longer buggy.
- All existing ATC and LuaATC setups still work like before, you don't need to change anything.
- During the update, about half of the trains changed their driving direction while retaining their speed. (this was an inevitable result of a change in the save mechanics). This means, you will possibly need to re-start your automatic lines, as train jams may have occured. This is a one-time effect and will not re-occur.
- It is now possible to utilize the interlocking system. Requests for the appropriate privilege can be directed to qualified moderators. The privilege will only be given out to trustworthy players.

Due to the event described above, pretty all railway lines, including the subway, are currently out of order. We are going to make them work again in the next few days. I have already restarted Line 2a (Origin<>Edenwood), to confirm that everything works.

If you notice any bugs or problems with trains now, please report it on http://bugs.linux-forks.de/advtrains.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Tue Jan 22, 2019 01:34
by h-v-smacker
— The trains either brake at a lower rate of deceleration, or react with a delay. As a result, trains on my routes now stop several blocks farther than where they used to (and were supposed to). Sometimes the trains even overshoot the platforms by several blocks.

— I lost two shunters when taking them off the tracks. Literally nothing given back. Same with a yellow subway wagon, no iron, no nothing. Apparently the "giving back" mechanics is completely broken. Previously it gave back nothing only when your inventory was full (which is also a bug), now it gives nothing at all times (which is a superbug).

— The switches aren't working exactly like they used to. The three-point-turn at Island station that used to work before (it used the trick that after the train drove "against the fur" on a switch it was treated as if actually set in that direction for a while) now just sends the train back to Neverbuild instead of moving it to the outbound track. I see it's a desired effect of train reversing, but still I liked that feature...

— Placing advtrains:subway_train on tracks makes advtrains reset itself, no train is actually placed.

— If you assign a signal to a TCB, and then destroy the TCB (that is, before creating a section, or after deleting them), then clicking the remaining signal causes a crash.

— If you destroy a TCB while it's still a part of some route, clicking on signals involved in that route also causes a crash.

— If you set a route involving several interlocking segments in a row, clicking "proceed to next" on every intermediary TCB, the system is supposed to release the individual segments that the moving train has already cleared, right? Because when I set this up, the first signal turns green only then the train clears the whole route...

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Tue Jan 22, 2019 11:56
by orwell
h-v-smacker wrote:— The trains either brake at a lower rate of deceleration, or react with a delay. As a result, trains on my routes now stop several blocks farther than where they used to (and were supposed to). Sometimes the trains even overshoot the platforms by several blocks.
The acceleration/brake dynamics should not have changed, and I don't know what the cause of this could be. Is it a problem for you to readjust your appliances, or are you OK with it?
h-v-smacker wrote: — The switches aren't working exactly like they used to. The three-point-turn at Island station that used to work before (it used the trick that after the train drove "against the fur" on a switch it was treated as if actually set in that direction for a while) now just sends the train back to Neverbuild instead of moving it to the outbound track. I see it's a desired effect of train reversing, but still I liked that feature...
Hm, I considered it a bug, and more than one player asked me about why it is this way. I'm afraid I can't make this bug reappear quickly.
h-v-smacker wrote: — If you set a route involving several interlocking segments in a row, clicking "proceed to next" on every intermediary TCB, the system is supposed to release the individual segments that the moving train has already cleared, right? Because when I set this up, the first signal turns green only then the train clears the whole route...
What I mean by this is something different. Interlocking follows the principle that between two trains, there has to be a red signal. To set a route, the full route (up to the next signal) needs to be free of trains and other routes. However, another route that only uses the rear part that the train has already passed can be set. See the image as illustration.

I've fixed the other problems you reported. Thank you a lot.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Tue Jan 22, 2019 15:44
by h-v-smacker
orwell wrote:The acceleration/brake dynamics should not have changed, and I don't know what the cause of this could be. Is it a problem for you to readjust your appliances, or are you OK with it?
I have checked the routes from Stallmangrad station and the subway. There is a consistent shift of several blocks compared to the stopping positions that I planned for, on every station. Of course I can move the braking ATC tracks the same several blocks away to compensate (switching to TSS will mean a lot of track work anyway, so this is pocket change), but I think the underlying cause is systemic. Maybe it's a change in advtrains mechanics. Or maybe it's the server who's now processing the movement of trains with a delay...
orwell wrote: Hm, I considered it a bug, and more than one player asked me about why it is this way. I'm afraid I can't make this bug reappear quickly.
Well, that is a bug, it's just a bug that has already been used as a feature... (
orwell wrote: What I mean by this is something different. Interlocking follows the principle that between two trains, there has to be a red signal. To set a route, the full route (up to the next signal) needs to be free of trains and other routes. However, another route that only uses the rear part that the train has already passed can be set. See the image as illustration.
Ok. So it follows then that in order to allow trains to move with short intervals (like on a track with regularly placed block signals in OpenTTD), such chained routes should be avoided? So if I have a long chain of segments, and I want the trains to move forward once the preceding train advanced to the next segment, it should go S1 -R1-> S2 -R2-> S3 -R3-> S4 ... and not S1 -R-> S2 -R-> S3 -R-> S4 (Sn = signal, Rn = route)? I.e. there should a separate route inside every segment, not one big route linking several segments?

What is the use-case for a route spanning several segments then (excluding passing several segments with track switches, of course)?
orwell wrote: I've fixed the other problems you reported. Thank you a lot.
Thank you!

PS: with respect to destroying wagons, there is another oversight: you can destroy freight wagons that have something inside, and the contents simply get destroyed.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Wed Jan 23, 2019 12:13
by orwell
Warning
There appears to be a bug in the execution of automatic brake commands. This applies to both the ATC "B" command and the train safety system (LZB) that makes trains stop in front of signals.
This has so far led to train's braking distances increasing by about 3 nodes, however braking completely fails when 2 consecutive B commands are given (see also http://bugs.linux-forks.de/advtrains/89.html)

EDIT: The bug regarding LZB seems to be fixed. Time will show whether the other problems still persist. Keep in mind that trains stop about 2 nodes in front of the signal influence point.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Wed Jan 23, 2019 13:01
by gpcf
The question is where the 3 blocks come from. Have you measured how big the distance is? If it really is the globalstep, the distance should be about the distance the train runs in 0.1 seconds.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Wed Jan 23, 2019 17:42
by orwell
The debug output saying "step_dist" tells the distance the train moved in the last step x1000.
Since dtime is now always 0.2 (advtrains clips this internally), this distance is exactly 15*0.2 = 3 nodes
However, the 1 step between "ATC command received" and "start braking" existed already in master.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Thu Jan 24, 2019 11:40
by gpcf
The dtime used to be 0.09, so that might be the difference.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Thu Jan 24, 2019 22:02
by orwell
Today I pushed the "point speed restriction" rails and the first version of the "stop rail" that is supposed do successively replace ATC-based railway operation. Since my exam period approaches, I will from now on only fix bugs found in the advtrains TSS version. I will then officially release tss as stable once it has proven working on this server for 1-2 weeks.
I won't have much time to play MT over the weekend. Have a nice weekend.
@gpcf, please pull once more

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Fri Jan 25, 2019 01:29
by h-v-smacker
Thing about ARS: the preemptive path reservation should be possible to disable. Consider the signals around a station in outbound direction: if they are close enough to the point where the train stops, they are toggled when the train just pulls in, preventing any train from the opposite direction to pull in as well. Granted, this isn't much of a problem when the trains stop for 10-20 seconds at a time. But what if a train is sitting in the station for several minutes? On the other hand, if the train were to reverse and pull out the way it came, the exit signal in _that_direction would only be toggled when needed.

It would be beneficial to have a setting in ARS rules (like some NP flag) saying that the path should only be reserved when the train actually passes the point of influence. After all, this setting is needed only for cases of low-speed approach, so the train won't miss the signal, as there will be plenty of time to react. This way, you won't have to place exit signals far from the station to avoid paths being reserved way too early.

PS The Stallmangrad-Personhood mainline along with Neverbuild branch has been converted to TSS/ARS

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Fri Jan 25, 2019 22:31
by orwell
This is one of the functions that the Stop Rail will implement. It will "suspend" ARS temporarily, until the train is about to depart. There will also be a switch for disabling ARS on the Onboard Computer. If required and wanted by players, I might also add an ATC command binding for that switch
(The stop rail is not finished as it is now)

I already made a draft of a timetable system that would allow for sophisticated train operation. But I think I won't get to implement this in the near future.

Setting the route "on pass" would not be easily possible, because the train never actually reaches the IP (as you've already noticed :( ), and there's another problem with that: If parts of the route to set are still blocked for some reason, the train would still stand in the station, but with closed doors, which is not comfortable to late passengers...

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Fri Jan 25, 2019 23:19
by h-v-smacker
orwell wrote:there's another problem with that: If parts of the route to set are still blocked for some reason, the train would still stand in the station, but with closed doors, which is not comfortable to late passengers...
I don't think that a slight delay until the path is freed is really a problem. Outbound paths should be rather short, as a rule. It's not going to be worse than in the current subway system, where trains sometimes wait in the tunnel. In my opinion, preemptively blocking the path without immediate intention to use it is a much more troubling issue. It prevents a station from working at full capacity. Having an ATC command for ARS control would actually be a nice solution as well... because then it would be possible to control when the train actually requests the route (In my use case, I would obviously put it after closing doors/reversing, right prior to departure). So the train would first disengage from the ARS and pull in, and later engage the ARS and pull out.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Sat Jan 26, 2019 22:37
by h-v-smacker
On stop tracks: they should be able to differentiate by LN/RC. That way it would be possible to arrange different behavior for various trains on the same track. It would be very helpful if some could be reversed while others left running in the same direction.

On TSS/ARS in general: it should be possible to tie Andrew's Crosses to a track segment, so that they engage when it is occupied. I think that's the last "big thing" missing.

Also on usability: there should be two buttons to set route instead of one: "Set route" and "Set route and enable automatic working". When you set a lot of simple block signals, this improvement will cut down the amount of clicking and mousing drastically.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Sun Jan 27, 2019 12:09
by orwell
The first thing is exactly what I had planned, and what I will do next.
Regarding level crossings, I planned 2 operation modes for them, as they are in real life:
1. Level crossing is integrated into the signal box, working similar to route locks. (Crossing closes when route is set)-> useful for crossings near stations. This is already possible in a limited manner.
2. Crossing on running line: This only needs to be closed while a train is approaching. I hadn't thought about how exactly these should work. Just connecting those to the "blocked" state of a section seems like a simple yet good idea.

I thought about adding a simple "Level crossing controller" node that is simply a "setstate multiplexer", so it is easy to add more Andrew's crosses without changing all routes. That could also serve as controller for 2.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Sun Jan 27, 2019 18:44
by h-v-smacker
orwell wrote:The first thing is exactly what I had planned, and what I will do next.
Regarding level crossings, I planned 2 operation modes for them, as they are in real life:
1. Level crossing is integrated into the signal box, working similar to route locks. (Crossing closes when route is set)-> useful for crossings near stations. This is already possible in a limited manner.
2. Crossing on running line: This only needs to be closed while a train is approaching. I hadn't thought about how exactly these should work. Just connecting those to the "blocked" state of a section seems like a simple yet good idea.

I thought about adding a simple "Level crossing controller" node that is simply a "setstate multiplexer", so it is easy to add more Andrew's crosses without changing all routes. That could also serve as controller for 2.
I honestly don't see a need in some fancy mode. If the track sections around are very long (hundreds of meters), the crossing can just be arranged within its own shorter section. What would be handy, however, is an ability to connect a crossing sign to more than one track section, activating it on any of them being reserved, and deactivating on all being clear — to account for parallel tracks.

PS: A note on using on-board computer to set routes. It's impossible to do, it seems, when there is a route that is set by ARS (default, or matching LN/RC). If there is just a bunch of routes, the driver can pick any. If none of the routes are activated by ARS, same. But if ARS wants to assign a route, there is no way to overpower it but to get out, walk to the sign, and set a route that you want. If you try to do it from cabin, the ARS will re-set the route it wants before you can press the buttons to set another.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Mon Jan 28, 2019 21:03
by CalebJ
Sorry to change the subject, but here goes:

The server puts a lot of focus on trains, and the machine world (mesecons, pipeworks, digilines ...). I really appreciate the fact that Linuxworks has no mobs, but perhaps make it a bit easier as well, by making lava kill a lot slower, and adding a Hazmat suit for radiation. This would put even more focus on trains and machines, and keep the focus off of looking for bones.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Mon Feb 04, 2019 13:33
by h-v-smacker
The server is lagging terribly today. Most of the time I cannot even connect, and in couple cases when I succeeded, i could barely do anything...

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Mon Feb 04, 2019 14:07
by gpcf
The server lag is really more than usual, even my ssh no longer works. I got to find another mapping schedule that will hopefully not wreck the server.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Mon Feb 04, 2019 17:07
by Hume2
I couldn't connect even when the server was empty. One thing is strange here: The mapping lag is each time different. Sometimes it's soft and sometimes it's terrible.

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Tue Feb 12, 2019 13:36
by gpcf
New interlocked lines have opened.... They are in testing operation right now, but they seem to be working fine.

Image

Re: [Server] LinuxWorks Next Generation (Lots of trains)

Posted: Mon Feb 25, 2019 14:33
by orwell
The second half of current interlocked lines:
Image
The light green line is roughly outlining the course of the lines in gpcf's map. You need to merge both maps in your mind to get a complete map.