The International Simutrans Forum

 

Recent Posts

Pages: [1] 2 3 4 ... 10
1
Simutrans Extended Development / Re: bidirectional and can_lead_from_rear
« Last post by Ves on Yesterday at 05:52:12 PM »
True, the symbols might look bad, however, I mostly used the ASCI-art to illustrate my point.
Thinking about it, what would it look like if you did that with your graphics?
2
Thanks for pointing it out. I've amended the title to something clearer.
3
Simutrans Extended Development / Re: bidirectional and can_lead_from_rear
« Last post by Vladki on Yesterday at 10:23:38 AM »
With such a complicated possible configurations, I think if it would not be easier to have a smaller set of "typical" configurations and let everything unusual reverse using wye... with significant time penalty.
4
Simutrans Extended Discussion / Re: All info in signal window
« Last post by Vladki on Yesterday at 10:18:57 AM »
Yeah, a feature which shows the catchment area of a signalbox would indeed be useful!
I like that idea. Not only for signalbox but also for signal. Just using the same graphics as for stop coverage would be nice.
5
Simutrans Extended Development / Re: bidirectional and can_lead_from_rear
« Last post by Ranran on Yesterday at 04:15:21 AM »
Considering my algorithm, it will split between 8/9. the 9+10 will be considered as the brake van sequence - moved to the other end and rotated. 1 rotated too. Next time 9+10+1 will move together

Maybe, reverse the direction of black locomotive until the last locomotive is reached and swap the numbers if two or more purple locomotive are connected.
The number of black powered vehicles is counted and the reversing time is increased accordingly.


2) =<__>=
If a vehicle with this configuration is sent out alone, it can not connect to any vehicles outside the depot.

3) =<__>=<__>=
A convoy in this configuration also cannot split or connect other vehicles at either end.

4) <__>-(__)=
I thought it was necessary to distinguish whether cab side could be connected, but I think this display would be confusing.
Because the bar in front of the vehicle seems to represent a coupler. Actually, it is a notation often used in railway magazines and websites.
That is, it looks like the opposite meaning.
Those who saw the picture would think that the cab side without the coupler can not connect anything.
6
Simutrans Extended Discussion / Re: All info in signal window
« Last post by Jando on May 25, 2019, 11:45:40 PM »
Yeah, a feature which shows the catchment area of a signalbox would indeed be useful!

You never use the window to debug problems in your network?

Not really no. Of course now I could claim that my networks don't have problems, hehe. Okay, more a result of trial and error, by now I have figured it out. But then I mostly play before power boxes are a thing thus it's practically all absolute block signalling on my lines anyway - and absolute block is a pretty straightforward thing. Stop signal, distant signal and combined signal - not much choice to create problems there. :) And when I get a problem it's usually that I mis-clicked and placed a stop signal instead of a distant signal thus trains slow down where they should not.

Really, the only info in the signal window I need is the distance to the box and the type of the signal, the latter mostly because one needs to look very carefully to see the difference between a stop signal and a distant semaphore signal.
7
Simutrans Extended Discussion / Re: All info in signal window
« Last post by Ves on May 25, 2019, 10:11:04 PM »
Yeah, a feature which shows the catchment area of a signalbox would indeed be useful!

You never use the window to debug problems in your network?
8
Title is misleading. Double-decker busses are not meant to pass under low bridges so if "A few double-decker buses cannot pass under low bridges" the behaviour is working as intended. However by the sounds of your post you meant to say "A few double-decker buses can pass under low bridges" which is unintended behaviour.
9
Patches & Projects / Re: Line Scheduling for simutrans standard
« Last post by Leartin on May 25, 2019, 11:49:01 AM »
Say a cycle 2^22 ticks long, independent of the bits_per_month setting.
If you happen to play with 22 bits per month, it syncs up perfectly
If you happen to play with 20 bits per month, you set the schedule for four months at once.
If you happen to play with 24 bits per month, you can only set the schedule for a quarter of a month, and the other quarters will be repetition.

Tick 0 could be something like the first tick of the first month of year 0. That would mean with 20 or 21 bits per month, tick 0 would be (beside others) the beginning of each year, with 19 bits per month, it would be the beginning of each even year, with 18 bits per month, it would be every fourth year, and the gap doubles from there. This would be consistent for network games, and can be grasped by a player.


As far as using such a system internally, sure. However, one could be extra clever about it.
> The ticks don't sync up to displayed time nicely. This would not matter if the player could actually operate at tick precision and choose a value between 0 and 4194303, but that sort of precision seems too much when practically, it's probably enough to go with seconds. I suggest a time unit consisting of 728 ticks. Of this time unit, 5760 would make up a cycle. If that cycle lines up with the month, each unit would be displayed as 7 minutes and 30 seconds. Therefore, at bits_per_month=21, you can use quarter hours to set your schedule, and at bits_per_month=20, you still use full hours. It's pleasent down to 17bpm and 8h precision, though I wonder if such short bpms are used.
Of course it does not line up that nicely in reality, using 5760 units of 728 ticks length does not fill all 22bits, but rather leave 1024 ticks unaccounted. Those are just the last bits in which no schedule happens. The imprecision you get from that is about a second, it hardly matters in practice.
A train schedules for time.unit 5759 would be displayed as "30th day, 23:52(:30)", but it would actually depart at tick 4192552, which in a 30-day month would be "30th day, 23:42". Really insignificant, considering we also have 31-day-months, at which the same train would depart on the 31st, but we surely don't want the displayed schedule to shift likewise.

> Even if the cycle has a fixed length internally, that might not need to be shown to the player. I think it would still make more sense for them to say "I want 3 trains per month" rather than "I want 12 trains over the course of a cycle that is 4 months long". This option should be unchanged. If you play with bpm 23, you simply can only use even numbers for the number of trains per month, since it's the same cycle twice, and divisible by 4 in bpm 24. However, this would not go the other way, with quarter-trains-per-month in bpm 20. Likewise, under normal circumstances a manual timetable would always be planned for a month, and if a cycle contains several months, the others are simple repeats. Some kind of "Use monthly schedule" setting which is on by default, and needs to be turned off to allow time units that reach in the next month, while simultanously turning the month-cycle off. Essentially, from the players perspective, everything is set up using in-game time values and monthly cycles, while in the shadows, it's converted to ticks on a fixed cycle length.
10
A few double-decker buses do not have the is_tall parameter set in their .dat files. Namely, AEC NS-Type, AEC K-Type, Leyland K2, MCW Q1, and Leyland Atlantean AN68.

I have fixed these and started a pull request which can be found here. This should be an easily incorporated pull request.
Pages: [1] 2 3 4 ... 10