Moderator: OpenTTD Developers
Is that correct? My understanding is that it can load current and old trunk versions and the current cargodest version, but not old cargodest versions.PhilSophus wrote:Unfortunately, now you can not load cargodest-timetable V1.20 games with cargodest-timetable V1.30. But both can load games from older cargodest and trunk versions.
and playing a few months, somehow 2 out of 3 trains with shared order were almost an entire timetable too late. It seems like somehow their order got mixed up but I don't get it yet. Loading an old savegame and fast-forwarding doesn't give the same problem, which makes it harder to track the problem down.Yes that was me, and I don't recommend it to you. As the savegame system is not designed for such things as branches, my approach was rather hacky.PhilSophus wrote:[...]Maybe I should have taken the approach of splitting the savegame version space as someone already did with his patches (wasn't that you, Roujin?).[...]
As cargodest is already a patch to trunk, you might actually be right.Tekky wrote:Is that correct? My understanding is that it can load current and old trunk versions and the current cargodest version, but not old cargodest versions.PhilSophus wrote:Unfortunately, now you can not load cargodest-timetable V1.20 games with cargodest-timetable V1.30. But both can load games from older cargodest and trunk versions.
Hehe, now that is a very good reason not to use that system (besides being lazy)Roujin wrote:I can only say, save yourself the hassle. If people are annoyed that their savegames keep breaking, they can go bug the devs to include your patch
That was my first idea as well but I couldn't recreate the problem in the few minutes I had to try. If I'll observe otherwise I'll post againPhilSophus wrote: Edit @bokkie: I have watched your game for bit and haven't observed the effect with the same vehicles but something similar with another line. I suspect, the reason is the following: You have very tight timetables and have servicing enabled (you should provide more overhead for catching up). Both directions of the ring use the same depot for servicing (you should set the other one as service depot for the other direction) and may thus interfere with each other. Normally, the vehicles can catch up their delay of 7 days due to servicing, but if a vehicle of the other direction is in the way, the delay may get larger. Additionally, more passenger could have piled up, causing a longer station turn-around further increasing the delay. If this happens, the delay keeps increasing. At some time the delayed train might even be overtaken by a timely train when in depot and then be stuck after this train.
So I suspect, it is not a bug, but normal behavior. If you see that behavior again and think my explanation is wrong, please post a savegame of before and one of after the problem.
. BTW thanks for the patch, seems like a worthwile addition!BTW: Sending the in-time train to depot and letting the other two trains overtake solved the problem within a bit more than a year without pressing "reset lateness" or letting it overflow. The two late trains were indeed stuck behind the other one. So, you had enough overhead, but were missing a possibility to overtake. I've let it run in express mode for a few hours after this, but they kept in time on average (always fewer than 10 days delay).bokkie wrote: That was my first idea as well but I couldn't recreate the problem in the few minutes I had to try. If I'll observe otherwise I'll post again
Not exactly, it calculated the time from start of the timetable and ordered by this time. This patch builds upon this code (you might have noticed that I referenced MagicBuzzes patch), so, this one works similar in this respect, although it doesn't sort the shared vehicle list permanently but builds an internal sorted list just when headways are requested.AndiK wrote:Hmm. Didn't the original Autosep-patch order trains by some kind of FCFS approach at the first station in the timetable? If a late train had been overtaken by another one, the train would take the place of the late one. At least this is what I believe how it worked. ^^
Just be careful: I use some 32-bit signed integer counters measuring in ticks since the year 0. This means 79000 years without daylength, but I can not guarantee that nothing overflows if you use a daylength factor.BlueEagle_nl wrote:Someone tested this patch with Daylength already?
If you think the wiki is incorrect, quote the exact lines, and report which page or pages they are on.Regiovogel wrote:- this is my own case - I don't understand what the wiki says what files are needed really. (On the one hand, it says "install this", and a few lines later it says "do not install, just copy some files out of it")
), the line with the closing } (Of course I am aware that I don't know the source - If there's a reason for the way it works now, then so be it) Great patch, really. I've never had as much fun with passengers as with cargodest and RTT. 
I'd still like my proposal No 1 better. 
Just while reporting the things which didn't make sense for me, I read some information closely enough this time and some things are clear now... Shame on meDaleStan wrote:If you think the wiki is incorrect, quote the exact lines, and report which page or pages they are on.
If you think you followed the directions, report the exact error message(s).
Sorry for being off-topic, but I had the same problems as you. Eventually, I threw away TortoiseSVN for this reason and reverted to the official SVN client, which uses text mode. For applying patches, I first used the "patch" program of GnuWin32, but this program was only able to handle Windows and not UNIX line endings. So I finally tried the "patch" program from this site, which is at least five years old, but works perfectly with both types of line endings.Regiovogel wrote:Now the question how to apply patches is left... many patches are not compatible with TortoiseSVN, and a whole lot of patches which are made to work with BuildOTTD are rejected as "unknown patch format". (not to tell about the problems since the server moved, but that's pretty off topic here)
After resolving those problems, I could eventually be able to compile it...
My thought when in implementing it like it is now was: The user knows what he is doing. He may choose for which vehicle he pushes the headway button. I've though about the following alternative to the current behavior: Starting at the vehicle you pushed headway for, use a negative headway for vehicles between first order and the vehicle which executes the headway and positive headway for the vehicles following it. So, you could still define the reference point of the headway but vehicles wouldn't have to wait for a full round. Please all of you make comments which behavior you would prefer.AndiK wrote:Concerning headways/Autosep: Why not use the FCFS method I thought MagicBuzz's patch already was using? Right now, timetable separation might get confused when you build additional trains. I've had trains standing in the first stop for hours on end with a big traffic jam at the entry signal. Idea: Store the time since the last vehicle left the first station in the list. The next vehicle arriving (regardless of any order in any internal list that no user will ever see) gets "last_train_dep_time + headway" set as its own departure time. This could save you one list and quite some confusion at the station.
One of the main design goals of my patch is retaining control of what is happening, while not having too much micro management (which it will always be, that lies in the nature of timetables). That is, the focus is not on having it all automatic, but on having the control (yeah, call me a control freakAndiK wrote: A button for Auto-Auto-Headway. Changes Headway as soon as trains in the shared timetable get created/removed and/or started/stopped [in a depot].
) So, I prefer that the user has to give an explicit order. Pushing headway is not that much work.Makes sense. You have the possibility to change the value anyway before executing. So, I probably should always preset the value. If you want another value changing from zero or a reasonable preset doesn't make that much differenceAndiK wrote: Swap the headway button functions. I haven't used manual headway a single time. Auto-hw should get priority here, IMO.
I click most of the time on just any vehicle when I've changed something in the timetable/added vehicles to auto-seperate them (headway), so behavior that accomodates this has my preference (and is the most fool-proofPhilSophus wrote: My thought when in implementing it like it is now was: The user knows what he is doing. He may choose for which vehicle he pushes the headway button. I've though about the following alternative to the current behavior: Starting at the vehicle you pushed headway for, use a negative headway for vehicles between first order and the vehicle which executes the headway and positive headway for the vehicles following it. So, you could still define the reference point of the headway but vehicles wouldn't have to wait for a full round. Please all of you make comments which behavior you would prefer.
). .
.This is strange. What do you have the patch setting pf.yapf.rail_pbs_cross_penalty set to? In order to find this out, enter "patch pf.yapf.rail_pbs_cross_penalty" in the OpenTTD console. I think the default value is 300.bokkie wrote:There seems to be a bug in Tekky's v1.30 build with cargodest, YAP(P/F) doesn't seem to work right. Trains always want to choose the shortest route, even if that isn't a free path and there's a free path right next to it which is 1 tile longer. Playing with the v1.00 without cargodest the same error seems to occur, look at the screenshot provided. Or am I doing some wrong signalling here... haven't been playing with many trains for a while
Users browsing this forum: No registered users and 20 guests
