- This topic has 26 replies, 9 voices, and was last updated 9 years, 2 months ago by
.
-
Posts
-
I noticed trains in TF can’t leave the highlighted line route under any circumstances. This may sound resonable as noone wants trains to get lost in network, sadly it makes many realistic designs disfunctional & makes networks really shalow & ineffective.
One example being a simple “Optional sidepass”:
This will cause deadlock in TF while it should not, if trains were not completely blind & following pre-calculated paths.Solution: When train enters “Waiting for free path” mode, let it try to search for an alternate paths to the next destination.
As much as I detest this practice. I will suggest LTP š
You can use 120 km/h switches on your passing loop, or use the “slower”part to handle empty traffic.
I really don’t see how this can be useful outside of this quite niche situation.
I use those passing loops / siding so that they are built slightly closer to one town and the train arriving first is taken to the loop / siding. This allwos the lattter arrival to go through in full speed. Just like in real life.
I really donāt see how this can be useful outside of this quite niche situation.
Stations for example, trains from the same line would no longer be bound to a single platform. With priorities later on, faster trains couldĀ overtake slower ones.
But most importantly it would work more realistically, it is in OTTD this way for a reason.
BTW, I would not call sidepasses a “niche situation”, as network grows, I need them left & right.
Well.
This is the part where I say “LTP” š
This is not OTTD. This is TF. It follows different approach for its cargo model and traffic management. The binding of lines to platforms is actually a feature. I have already discussed that dynamic allocation of platforms can be as much of a detterent as it is a feature: http://www.train-fever.com/forums/topic/suggestion-platform-selection-and-more-platforms/ . Wise use of waypoints, to sort lines by their speed and target, in order to ensure least amount of switching, can achievie statistically better results.
In your case, the niche approach is to have a “main” and a slower “detour” if main is occupied. However, this is suboptimal. If an empty train occipies “main” then loaded train will have to use the much slower “detour” immedietly degrading line performance. Unlike in TTD, where in such case you’d get less payment, in TF you’ll pay with slightly diminished production at the source.
In TF it is best to optimize the “loaded” path for maximum speed at all times. Thus such optional pathing would be a detterent. Also, take into account that in TF, unlike in TTD, you can control the speed at which train goes on the “off” direction of the switch, or even create a symmetrical switch, so both branches of the passing loop would have the same throughput.
Just don’t create 46km/h switches everywhere.
What is so bad on letting train try find an alternate routes when it runs on block instead of deadlocking & sitting here like a TURD.
I labeled this thread as SUGGESTION for better & more resonable pathing system that will work for TF same as it does in OTTD. It will only ADD to this game, add more depth & possibilities.
Dynamic (free platform) alocation will actually drastically improve default station behavior which is really unreliable. U cant really be sure what platform line will ALWAYS use, unless u setup waypoints, which will work the same even for dynamic allocation.
Algorithm works like this:
- find fastest path (respecting one-ways) to next stop or waypoint
- follow it untlil “path blocked”
- try to find fastest unblocked path (respecting one-ways) to next stop / waypoint
- SUCCESS – go to 2. Ā FAIL – repeat 3.
In TF it is best to optimize the āloadedā path for maximum speed at all times. Thus such optional pathing would be a detterent.
This is literaly a feature that will only reduce deadlocks without negatively affecting gameplay. It will respect any player made waypoints & one ways.
The deal is, that the game already does so. Follow a vehicle with its properties open. Everytime a vehicle cannot reserve a path on its line, it will display “waiting for free path” and will start braking. This is the time when a new path is searched for.
Deadlocks are not caused by poor pathing, but by incorrect junction placement and construction. This remains true from the earliest versions of TTD, through TTDpatch and OTTD. Sure, OTTD has more elaborate signalling system, but its most advanced signalling – path based signals, are what TF implements.
The only difference is the static pathing of TF. Sure, OTTD can do dynamic platform allocation, but does it so in the dumbest way possiblem, and then it is useful just for drop-off stations near big industries and for passenger traffic. If you want to have passing loops in OTTD with more then three trains then you need to set up the whole shebang just like you would in TF – using path signals. Otherwise the system will deadlock.
My point is – TF offers you 95% of functionality of OTTD’s signals, but also offers what OTTD cannot offer. Sure, having some features of OTTD’s signalling would be nice, even if because that would be less confusing for begginers. But I, personally, don’t see them as being all that useful.
Interesting factoid: in my last OTTD game ( about 3 years ago ) I have used only path signals in a manner identical to what TF does now.
I think if you can’t make it work with the current system, you don’t understand railways and signaling well enough in the first place. Deadlocks only result on bad designs and dynamic path selection would cause even more of them.
My advice is that you think first, then act and keep an eye on the line colour to see how the path is created to spot any issues with it. If you need to have 2 trains from the same line at the same station at the same time, it’s wrong anyways.
The deal is, that the game already does so. Follow a vehicle with its properties open. Everytime a vehicle cannot reserve a path on its line, it will display āwaiting for free pathā and will start braking. This is the time when a new path is searched for.
In that case, the bi-directional loop would work, it does not!
If TF has all content of OTTD (planes, ships), some simplfications may come acceptable, but it does not.
Unless I define waypoint for each line & platform, I experiencing 2 different lines picking same one & not recalculating if it’s blocked, even when there is one completely free.
Deadlocks only result on bad designs and dynamic path selection would cause even more of them.
How exactly? I never ever had problem with it in OTTD.
This is not OTTD.
Pathifinding is a way of finding best path between 2 points, it can work same for TF as it does for OTTD. Lines are system that says where train goes, not how it gets here!
If you need to have 2 trains from the same line at the same station at the same time, itās wrong anyways.
Better than having it standing on the main track blocking all other traffic!
Which again points to the fact that you need to forget the other games and learn to work on this one with more realistic approaches on designs. i’ve never encountered the issues you are on about, so for me this system works perfectly fine. Took a while to understand how the automatic signals work on the game and how i need to improve it with the signals but once i got that, it’s been smooth running.
Which again points to the fact that you need to forget the other games and learn to work on this one with more realistic approaches on designs.
Design I pointed in OP is 100% realistic & does not work in TF.
Automatic platform assigment system in TF is like Russian roulette, even upgrading track far away from the stations tend to recalculate everything & mess things up. This game must had been a nightmare before waypoints, glad I wasn’t there!
BTW, did OTTD had a waypoints? I can’t remember that I ever needed them.
Look for some sims (like TrainZ) for any idea of realistic signaling, TF looks like a joke in comparison. It is like comparing ARMA & CoD
It was indeed a nightmare. You would design a 2 track line and the game would be stuborn and make your line single track for the most part. No idea how that ever got past any QA. Signaling is indeed a joke. I wanted to create a more real world signalling look when designing my first lines only to discover that all my trains started getting stuck in each other’s way.
I don’t need to play games to know how real life signalling works š
You have to remember that there are “hidden” signals in the game and you don’t need to place every single one needed. On double track you can easily, following a real life scenario, make it directional and be done with it. Should there ever be a reason for a temporary bi-directional use, that can be easily changed.
Game is full of problems desperately needing a fix, but signalling isn’t one of them at the moment. It could be better, but it works perfectly fine when you understand it.Ā That Steel Talons example is realistic yes, but in real life every single train has it’s pre allocated path which would take it to that siding as per timetable. We can’t adjust the time aspect for the trains, but paths we have.
Also building one-way autoblock (the only one that works) on a long track is pain in the ass! Why can’t I pick one-way signal in build menu & make them with one click?
Why are there separate mechanical & light signal when there is literaly no difference between them? Just let them auto-upgrade in year when lights became common & use that free GUI space for a pre-set one-way.
- The forum ‘General Discussion’ is closed to new topics and replies.