Transport Tycoon Forums

Last night I seemed to be having my timetables overwritten as well, and I never touch the automate button - I just autofill on a test run to get an idea of timing then tune the schedule as needed to the network. Basically I had two trains on different branches stopping at one station, one on a 60 minute cycle, and the other at 90 min. Each train had a few extra minutes of slack built into parts of the schedule. The 60 minute train was given a start date at X:00, the 90 minute train at X:15, so that it would always arrive at the station 15 minute before or after the 60 minute train, ensuring that the platform was free. I noticed the schedules creeping 2 minutes forward each cycle for one train, and 2 minutes backwaards for the other, so that after a few cycles, both trains were trying to arrive at the station at the same time. The creep was actively overwriting the timetable, and I could watch the numbers change each cycle with both the departure board and timetable windows open. The timetable always kept the same total time of the journey (60 or 90 min.), and never said that the train was either late or early. I stopped both trains about 3 times to reset their timings. I don't recall this happening with just the departure board patch, as I am used to keeping very rigid timetables for my trains. This is my first time playingwith this pack, so i am unsure which particular patches might be causing this.

In the attached file, this is happening with trains 3 and 4. I am waiting to firm up the schedule for train 4 so that i can run train 1 to the aluminum plant without interrupting passenger service, but this has become a moving target with the creeping schedules. I will try to replicate this problem on a clean save with no .grfs and some illustrative .pngs later this evening. The attached save uses FIRS, HEQs, OGFX+ trains, eGRVTS, and maybe FISH.

Best,

I post here my special testing savegame without any grfs. The seperation gets broken when you have a goto-depot order in your schedule.

Edit: Posted a screenshot with a possible workaround for my "kind of" realism based games.

1. The train enters the station, unloads and leaves empty.
2. The train has the order to go to the waiting station. With the one-way signals in front, it has to take the track around the station and gets into the depot by force - without any order.
3. After the forced maintenance the train now enters the waiting station with "no loading". I hope cargodist is not confused with this because I dont want to have any passengers there waiting.
4. After that the train gets back to the main station ready for the next journey.

Any comments or other ideas?

BR 155 wrote:3. After the forced maintenance the train now enters the waiting station with "no loading". I hope cargodist is not confused with this because I dont want to have any passengers there waiting.

No it will be ok. There will be a link and maybe some passengers want to go from your station to your waiting station (don't know what effect the depot has in this case) but no passengers will be created in your waiting station...

Thank you for the savegames supermop and BR 155.
Unfortunately It wil take some time before I will be able to tell you what is going wrong. I will have to test clean trunk first to be able to tell how the behaviour is different from trunk's. But I will look into it.
As you both understand what it is you are trying to achieve would you mind testing with the autoseperation setting turned off to see if that makes a difference in regards to the changing start date, please.
Advanced settings -> vehicles -> Use timetable to ensure vehicle seperation.



Also I have tested the copypaste preview while pasting some more. It seems that it only works for rails with the changes I have made recently ... will need some more testing before posting the next version.

A really quick test with two kirbys on a 5 station line with each station 4 tiles apart, and each train stopping at only 3 stations seems to work. Topologically the set up is the same as my problem example, but each train has a 20 minute cycle instead. Even when I adjusted timing to be tight, they held to their original timetable. When I set them to conflct, the blocked train became late rather than readjusting its schedule. I will have to try a more complicated case with 3 lines later, but for now it seems the above mentioned setting solves my issue.

However, I found it was unexpected for autoseparation to affect two trains which did not share orders and did not at any point have the automate button pressed in the timetable window. It would be nice to be able to have autosep. active on some services, e.g. busses and metros, while preserving precise schedules for certain train lines. I guess that is a sentiment for the Autoseparation dev. thread.

Thanks, and best,

ChillCore wrote: As you both understand what it is you are trying to achieve would you mind testing with the autoseperation setting turned off to see if that makes a difference in regards to the changing start date, please.
Advanced settings -> vehicles -> Use timetable to ensure vehicle seperation.

Setting the start date works as intended when the timetable based speration is turned off. Just tested it with the above posted save. Even a goto-depot order doesn't disturb the manually set start date.

Thanx a lot for the investigation.

Thank you both for the additional testing. I now know where I have to go searching for the conflict. That does not mean that it is already fixed or that I will be able to.
Autoseperation is done by holding trains at stations, mabye that is is what causes the timetable start shift.

supermop, in addition to the above autoseperation has issues with waypoints.
Also I find it strange that two trains not having automated timetables and not sharing orders are affected, hmm ...

As for removing the autoseperation setting globally and enabling it per group, it was suggested before and I do think that it is a good idea.
I will have a looksie if it is possible as soon as I find some time.
As you may have noticed most of my time is going towards fixing issues in the More Height Levels patch at the moment.

ChillCore wrote:
As for removing the autoseperation setting globally and enabling it per group, it was suggested before and I do think that it is a good idea.
I will have a looksie if it is possible as soon as I find some time.

This would be great, but maybe it would be best to see if there ends up being any development on making groups smarter first.

ChillCore wrote:Also I find it strange that two trains not having automated timetables and not sharing orders are affected, hmm ...

The fact that it was a continuous drift rather than a one time adjustment, and that it served to effectively reduce the separation between their visits to the shared station rather than increase it was particularly annoying.

Great work so far, both here and in height levels.

supermop wrote:

ChillCore wrote: As for removing the autoseperation setting globally and enabling it per group, it was suggested before and I do think that it is a good idea.
I will have a looksie if it is possible as soon as I find some time.

This would be great, but maybe it would be best to see if there ends up being any development on making groups smarter first.

Regardles of smarter groups or not, shared order groups are shared order groups. I should have been more specific, sorry.

Also I find it strange that two trains not having automated timetables and not sharing orders are affected, hmm ...

The fact that it was a continuous drift rather than a one time adjustment, and that it served to effectively reduce the separation between their visits to the shared station rather than increase it was particularly annoying.

I can imagine that being annoying.

Great work so far, both here and in height levels.

Thank you.

ColdIce wrote:Build log
http://www.heypasteit.com/clip/OLL

and win32

Thanks!
It is working - but...

Maybe downloading the newer OpenGFX version from the online content would help you get rid of the message?
Exit and restart the game to make it active.

Kogut should probably have made it clearer that he is using the original base set

ChillCore has seen that but ChillCore gets no warning when he has selected the original sprites even when he has already selected them before starting the game.
ChillCore has done as the message suggested when he saw it too before I think.

ChillCore wrote:ChillCore has seen that but ChillCore gets no warning when he has selected the original sprites even when he has already selected them before starting the game.
ChillCore has done as the message suggested when he saw it too before I think.

But how can I update original base set? I dislike new (sorry for all artists but I prefer old)

=====
UFO signs when generating small maps

Small request for "set maximal heightlevel at foo" for heightmap generation

Kogut wrote: But how can I update original base set?

just use the openttd.grf shipped with the openttd bundle you use

Kogut wrote: But how can I update original base set? I dislike new (sorry for all artists but I prefer old)

You don't. The message says nothing about which base graphics set is missing sprite. (Maybe it should ...)
Just download the newer OpenGFX and restart the game without selecting OpenGFX.
EDIT: Ammler was here too.

UFO signs when generating small maps

Select other smoothnes and/or lower terrain type settings.
Or try a different seed.

it is supposed to be iceland.PNG

Your heightmap is not optimized for the height you have selected.
Select lower terrain type before generating the map or adjust heightmap for heigher levels ...

Kogut wrote:

ChillCore wrote:ChillCore has seen that but ChillCore gets no warning when he has selected the original sprites even when he has already selected them before starting the game.
ChillCore has done as the message suggested when he saw it too before I think.

But how can I update original base set? I dislike new (sorry for all artists but I prefer old)

OpenTTD (or at least trunk/testing/stable) ship a (New)GRF file with extra graphics for the original graphics (these include some new signals, canal edges, lots of GUI sprites, etc.). Each time OpenTTD requires new graphics we make sure we have a version of those graphics for the original graphics to distribute with OpenTTD. Shortly after we commit it to trunk, or even before that, the OpenGFX people draw the sprites and add that to their nightlies and over time it gets into their releases. The problem is that OpenGFX isn't packed with OpenTTD (it's quite huge), thus over time people are upgrading OpenTTD and then miss OpenGFX sprites. This causes bug reports simply because they did not update their OpenGFX, so we added this check for sprites to OpenTTD.

For OpenTTD with the original graphics this check isn't needed as long as people don't mess with things, but once they start messing with it you might get the error. In this case I reckon that you've got the metadata and "extra" (New)GRF somewhere in your global "data" directory, which is where OpenTTD finds it and it then uses that (old!) version with missing sprites. This then causes this nice warning. Maybe you once downloaded one of those "all-in-one" binaries and dropped everything from the data directory in your global data directory and now you're getting this nice error.

ChillCore wrote:

Kogut wrote: But how can I update original base set? I dislike new (sorry for all artists but I prefer old)

You don't. The message says nothing about which base graphics set is missing sprite. (Maybe it should ...)
Just download the newer OpenGFX and restart the game without selecting OpenGFX.
EDIT: Ammler was here too.

My opengfx is updated. [edit: to 0.3.1]

basically, re-download the binary and copy EVERYTHING across, especially the /data/openttd.grf