Transport Tycoon Forums

Yeah.....An all engines "Route" would be useful. But mostly you would only replace the vehicles of one route, unless you use the same engine for everything.

The all engines button would be useful for replacing track (as would a certain TTDpatch-like sign cheat) as I for one could not be bothered moving my 210 trains over to maglev or monorail because it is too much effort.

The game should be a little realistic. Switching the rail system to something else with a "sign cheat" is only good for debugging reasons.

Celestar

Well then give us a button to order our little men out to do all the work on the track. (i mean sign cheats with the cost switch on)

Celestar wrote:I somehow like this "shutdown route" idea. I'll have a look at it once the order system is refurbished. (read: sometime in 2005)

Celestar

Hay, is this roadmappped (I didnt see it the last time I browsed the roadmaps) I was about to start looking at the FIFO, waiting times (min, max), loading, leave if another arrives... options suggestion that keeps popping up to see if it could be done. But if the route system is to be redone it proberly wouldnt be wise to start.

One thing that me starting this might effect is the spacing options as the max and min times, leave if x trains are already waiting could be used to space things out.

I also think the stats would be good, didnt see any mention of the ablity to show all the trains using that route (I saw the number of trains, just not a way to list em) overall tho the shared orders system would cover most of routes, just needs a cool looking interface.

edit: Joker Proberly would be good if the sourceforge feature has a link back to this topic. (which makes me think, have I seen this on SFs feature list)

mbarashkov wrote:Let's think about route statistics and control. ...

There already exist 2 tools for easier orders management
- Shared orders (with list of vehicles, that share the same shared orders, available from vehicles "Orders" form) and
- Vehicle groups.

But there is not the "Routes list" by now.
"Routes list" is list (collection) of any orders. Any orders may be objects of this list. Even empty orders, f.e. like mexicoshanty show in routes_concept.png: http://www.tt-forums.net/viewtopic.php? ... 1&start=14.
This suggestion is natural, and such thing is presented in real life too. Because it is very usefull.

Here is an example, that makes perfectly clear, how usefull can be list of orders as objects, separate from vehicles:
We know, that planes in openttd crush sometimes.
Imagine, one of your aircrafts have some unique orders (route). Perhaps it's crushed and is deleted by system automatically over 2 weeks or 1 month. And you was not catching it to buy a new aircraft and copy them orders from crushed one. So result is: this orders (route) is lost. Now, if you deside to place a new aircraft onto this route (orders), you have to redefine all orders of this route again, one more time. If you can remember this at all. Else this route will be lost.
But, imagine, that routes (orders) are not childs of vehicles or aircrafts, but almost independent objects, assembled to the list. Then after crush of an aircraft, connected to route #1, you don't need to redefine orders of this route #1, but you simply assign a new aircraft (or any transport the same) to route #1 similar to copying orders or share them.
Any route can be orders or shared orders for 0 or 1, or more transport units
(any route is shared orders, but there can be 0 or 1, or more transport units, connected with it).
In fact, shared orders already are routes in this mining. But in openttd they are hiding under transport units, i.e. access to shared orders exist through transport unit's "Orders" menu, and there is no list of routes (shared orders) separately.

Here are some interesting options (especially, for airplane-based company), that could be possible with routes (shared orders), if they would be seperate objects, organized to list (or sequence with priorities):
1. Routes (orders|shared orders) could not be lost even if sometimes there is no transport units, that follow them.
2. Routes could keep instructions, what number of (how many) transport units have to share each route. For example, once some aircraft is crushed, system will replace it automatically with new one (if will have such instructions). If there are not enough transport units, then execute by sequence with priorities.
3. System could create routes automatically (if player ask it). For example, company have 10 airports in 10 cities (1 airport in each city). This is much more easy for player, if system automatically creates 45 routes to connect these airports each with all other (all combinations), instead of player have to do it manually.
// Combining 1, 2 & 3: system creates 45 empty routes and place on them aircrafts with order of descending potential of probable (expecting) future profit.

TopTechDreamer wrote:

mbarashkov wrote:Let's think about route statistics and control. ...

There already exist 2 tools for easier orders management
- Shared orders (with list of vehicles, that share the same shared orders, available from vehicles "Orders" form) and
- Vehicle groups.

But there is not the "Routes list" by now.
"Routes list" is list (collection) of any orders. Any orders may be objects of this list. Even empty orders, f.e. like mexicoshanty show in routes_concept.png: http://www.tt-forums.net/viewtopic.php? ... 1&start=14.
This suggestion is natural, and such thing is presented in real life too. Because it is very usefull.

Here is an example, that makes perfectly clear, how usefull can be list of orders as objects, separate from vehicles:
We know, that planes in openttd crush sometimes.
Imagine, one of your aircrafts have some unique orders (route). Perhaps it's crushed and is deleted by system automatically over 2 weeks or 1 month. And you was not catching it to buy a new aircraft and copy them orders from crushed one. So result is: this orders (route) is lost. Now, if you deside to place a new aircraft onto this route (orders), you have to redefine all orders of this route again, one more time. If you can remember this at all. Else this route will be lost.
But, imagine, that routes (orders) are not childs of vehicles or aircrafts, but almost independent objects, assembled to the list. Then after crush of an aircraft, connected to route #1, you don't need to redefine orders of this route #1, but you simply assign a new aircraft (or any transport the same) to route #1 similar to copying orders or share them.
Any route can be orders or shared orders for 0 or 1, or more transport units
(any route is shared orders, but there can be 0 or 1, or more transport units, connected with it).
In fact, shared orders already are routes in this mining. But in openttd they are hiding under transport units, i.e. access to shared orders exist through transport unit's "Orders" menu, and there is no list of routes (shared orders) separately.

Here are some interesting options (especially, for airplane-based company), that could be possible with routes (shared orders), if they would be seperate objects, organized to list (or sequence with priorities):
1. Routes (orders|shared orders) could not be lost even if sometimes there is no transport units, that follow them.
2. Routes could keep instructions, what number of (how many) transport units have to share each route. For example, once some aircraft is crushed, system will replace it automatically with new one (if will have such instructions). If there are not enough transport units, then execute by sequence with priorities.
3. System could create routes automatically (if player ask it). For example, company have 10 airports in 10 cities (1 airport in each city). This is much more easy for player, if system automatically creates 45 routes to connect these airports each with all other (all combinations), instead of player have to do it manually.
// Combining 1, 2 & 3: system creates 45 empty routes and place on them aircrafts with order of descending potential of probable (expecting) future profit.

An impressively large bump, whilst a useful contribution, might've been better served in a new topic with a link back to this one

There is a possibility to enhance lines management (orders lists management), like in "Simutrans" or in "Transport Fever", with existing tools in OpenTTD:

If there would be some NewGRF, with 0-cost and 0-capacity, and low-speed transport units of all types of transport, f.e. named "Lines Holders",
then player could use this transport units for holding lines orders lists: 1 unit for 1 line.

This fictive "Lines Holders" transport units could just be stopped in depot or hangar (and grouped in a special group "Lines Holders"), but after adding another new transport unit player could simply share orders of new unit with that fictive "Line Holder"-unit with no need to create new orders list even if no transport is running on that line, f.e. if the only plane on that line was crashed and deleted (with it's orders).

Please, who can create such a NewGRF with empty "Lines Holders" transport units, do it and after, please, report here, in this topic. Thank you.

why would you need new types of vehicles for that? just buy the cheapest vehicle you find, vehicles do not have running costs while stopped in depot.

Even the cheapest vehicles (or trains or planes) are sometimes too expensive. Especially, when game just begins and there is deficit of money.

In that situation you have so few trains that advanced line management doesn't bring you many advantages. Just clone trains that are running until you have sufficient money.

TopTechDreamer wrote:This fictive "Lines Holders" transport units could just be stopped in depot or hangar (and grouped in a special group "Lines Holders"), but after adding another new transport unit player could simply share orders of new unit with that fictive "Line Holder"-unit with no need to create new orders list even if no transport is running on that line, f.e. if the only plane on that line was crashed and deleted (with it's orders).

Instead of requiring a vehicle to be a "line holder", why not instead create groups which specify the route an aircraft is meant to take - I do this in my game for example, using a 3 letter code for the airports, much like what is found in commercial aviation. The group tool would allow 8 airports to be one particular route. I also do similarly with trains, where I specify the start and end point and use a code to specify what type of train it is (for example, my current German game has these based off of DB) - This allows a rough guide as to what each train is doing, and looking at the Cargo Distribution, allows me to see where these vehicles are going (and stopping)

The general idea presented here seems to focus on something akin to "Line(s)" of Simutrans and Transport Fever (probably also Cities: Skylines but it's not very relevant). While I can see their usability, the same "problem" that arose with these games are that the routes ("lines") are fixed; in Simutrans you need pre-signal to let them use other platforms, in Transport Fever there are none of. I'm not sure why exactly they sort of fall to each, is there any sort of shortcomings perhaps ? I'm not sure how things is within the pathfinders.

TBH I never really utilize such things to the max, I try to use trains than bunch of RVs, I try to use only single trains, most routes serve a unique source/destination (so while I can have lots of trains each trains only deliver from one raw source to a single processer), other times it's usually a passenger/mail service which have clearly different rolling stocks so it's easy to see which is which.

In the early stages of the Timetable Improvement Patch, I had an working implementation of routes as sequence of stations / waypoints / etc.
Routes consisted of RouteNodes, and a RouteNode was an abstraction for anything you might want to add to a Route, theoretically, it could even have been an arbitrary position on map.

My idea why I added that to the patch was
- support the concept of a route timetable, i.e. which short / long distance trains travel (timetabled) when and where on that particular route, presented in a straightforward way.
- provide suggestions when adding stations to an order list - when hitting GoTo Station <Foo>, it suggested all stations <Bar> that are reachable from <Foo> via some route; this way it was possible to add stations to an order list without the need to scroll and click them.

At some point I removed that feature from the patch to make it at least somewhat smaller and maybe more feasable with respect to trunk, i.e. I wanted to concentrate on the core functionality of the patch, and thus split off that part.

But the implementation is still buried somewhere in the early versions of the patch (as far as I remember, before I switched from file names starting with "tip" to ones starting with "stip").