Even the most dedicated players would find this too much. But imagine having to edit this:Īnd this is just for one train. My plan up to this point had always been to make players edit train runs. Only the final boss remained: timetable editor UI. Trains were running it, pax were planning on top of it. I had now system for timetables which I liked and was flexible. It does a simple thing (estimate the time with a 90% max train speed, then run the train at 100% on the tracks), and it also respects line tags, but its timing will probably be a bit off compared to real line legs. That being said it is not a fully traced path like a line leg path. This “glue path” is properly accounted for by the train run logic and its leg run time is used to adjust the time of the first stop of the line, so the timetable accounts for it. So in another design decision, it was made possible to mix and match any possible line with any other possible line, even if the “glue path” to transition from one line to the next is multiple hours. Initially I was going to force lines match on their final and first stops to make them compatible, but realized this made every 1.4 line invalid and every line design tip up until this point invalid. The main problem with this feature is the “glue pathing” required to go from one line to the next one. This also restores the old vision of having trains being independent of lines, which is of course the more realistic. So I decided to make it possible again for trains to be assigned to any number of lines, by making runs explicitly store which line they are going to run. It would be better to keep lines relatively simple and instead work on the new thing, which was trains runs. I was planning to improve lines with all sort of extra options to make them more flexible, but the more I thought about it the worse it looked. Up until this point the entire design of timetables had a big limitation: trains are forever fixed to run a single line. Final timetable design: multiple lines, runs, orders and automation ![]() This was the state of the AI in early august, it is now much improved. The previous video shows a busy station with many trains coming and going, and most of them making their timetable in time (with a buggy visualization, ignore the wrong platforms). Out of two months of development for 1.5, train AI implementation took a total of two days. Combining this with the existing max speed setting for lines, allows trains to catch up with their timetable, so it might be a good idea to reserve more than 10s of min. But if it arrives late and loads fast enough it will depart on time. The system of waiting extra time for loading pax still exists, so it can depart late if the reserved min. It is now used to calculate the departure time for the train stop, and the train will consider departing the station once that time arrives. stop time is no longer the minimal amount for the train stop. Trains about the fixed arrival time for a line stop, and if the line settings allow them to, they will run extra fast in case they are late. ![]() This forms a relative timing for the line, which is then translated to a real time when a train runs a line, based on the run start time. ![]() Line stops are still edited just like in 1.4, with leg speed control and a min. Then, only when finishing their current run, they will consider running a new run (usually the next one, but if it’s late enough it can skip one or more). So on spawn (including interventions) trains will be spawned on their current stop according to the time of the week, and assigned that run. In particular the “what to do now” code now looks up what is the run the train should be running at the moment it is asked to, unless the train is not done with its current run. Thanks to train AI “roll on rails” code being 100% decoupled from “what to do now” code, it took just two method changes to switch to timetables. The straightforward design of the run system not only helps pax and the line network logic to quickly build a timetabled map, it also helps trains run timetables easily. How the player interacts with runs was the big headache, so I decided to stop thinking about it for awhile and finally update train AI to 1.5 timetables. These runs are tightly packed and must cover 100% of the week seconds. Trains will have a sequence of “runs”, which is a simple combination of start time plus a line to run. NIMBY Rails devblog 2022-08 25 August, 2022 Timetable support for train AIĪugust started with the decision to base timetables on the “train run” system as explained last month.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |