Transport Tycoon Forums

I ment the line up if there A LOT of lorrys/bus in a line at this time the game moves them all to one side of the road evern if they can use both

2007Alain2007 wrote:I ment the line up if there A LOT of lorrys/bus in a line at this time the game moves them all to one side of the road evern if they can use both
[img]

As said before, just on top of post of yours, no such patch does exist.

sorry i only saw petert post befor mine

Ok, I understand now.

update to R17533

Since most AI's flood roads with buses, this is a very useful patch. Now its possible to build a bypass if a town or bridge is stuck with vehicles. Thanks for the good work!

EDIT: Seems it doesn't work with bridges and tunnels: There is no penalty for Vehicles on bridges or in tunnels.

sulai wrote:Since most AI's flood roads with buses, this is a very useful patch. Now its possible to build a bypass if a town or bridge is stuck with vehicles. Thanks for the good work!

EDIT: Seems it doesn't work with bridges and tunnels: There is no penalty for Vehicles on bridges or in tunnels.

Thanks for your praise

Indeed, you're right. I have forgotten about those "worm holes". I shall take a note and see if I can implement that for the next version. I have a feeling it might turn out difficult/"not feasable" though. Not sure if there's an easy way to find vehicles in a wormhole.
On the other hand, it must be possible, else we wouldn't have "can't demolish tunnel - vehicle in the way" error messages. Hmm, I shall see

The signals in tunnels and on bridges patch has the feature of showing all trains inside a tunnel when clicking on its entrance. Maybe you can use that part of its code as a start.

There has been a lot of changes to the pathfinder code in trunk lately. As a result the patch had a lot of rejects, but they were easy to solve (mostly related to the addition of new penalties to YAPF and NPF and a reorganization of the pathfinder code files). Here is a version updated to r18429.

I want this feature in trunk.

I suspect that "everybody knows" road vehicles aren't a robust service; and they resort to other solutions. My viewpoint is that a local bus service is a pretty basic element of transit planning. It should be easy to set up a reliable system, considering that there is no automobile traffic!

One certainly can increase a main rail station's catchment considerably by building disjoint stations. It's false to say that you only need to build a pair of distant physical stations in order to catch all the cargo production in between; but you can gather in a great deal by building several drive-through road stops, all logically part of the rail station. Set station spread high enough and you can cover a whole big city with one logical station this way. This approach is functional, in that it eliminates the need for feeder systems; but it is not terribly realistic.

I've seen some successful point-to-point road vehicle routes, where there is plenty of freedom of design and the demand for service predictable. I'd like to see, without a pathfinder improvement, a successful in-town pax service.

Road vehicles don't carry many pax; so many vehicles are needed. Long before the actual capacity of the road network is saturated, though, congestion causes terrible gridlock. I believe this is due to each vehicle looking at the network more or less statically and finding a "best" path from A to B. YAPF does not seem to be completely deterministic but, given a set of vehicles that all need to make the same A-B trip, most will choose the same route, even if there is an open alternate. So, the best route becomes the worst. I've tried increasing the number of physical stations, moving the stations, moving depots, and one-way roads. No matter what I do, one route will be "better" than the rest -- and, therefore, become the worst.

It may be possible in theory to straighten things out by designating some stops as waypoints and issuing 'via' orders to some vehicles. I'm not sure if this will work at the limit but I say, at some earlier point, it's a bit silly. Put down enough waypoints, issue enough orders, and you have simply removed the pathfinder from the problem. Instead of shared orders, you have individual routes for each bus. Even micromanagers have to let the coffee perk on its own.

I have a test scenario here for your amusement and my challenge: Serve Harrisburg with road vehicles only. I want to see all station ratings at Good or better, preferably much better; and essentially complete coverage of the town. You may move stations and depots, build as many as you like, and even combine stations. You may not demolish entire blocks of town to build elaborate private roads. Profitable solutions are better than unprofitable and honest savegames better than cheats. But I'll be interested to see any solution.

The scenario starts in 1850 and uses horse carriages. Obviously, better road vehicles are available later -- but by then, Harrisburg will be a much larger town. If you fast-forward a few decades (or a century), fine. But I want to see your local road service work continuously in your chosen era -- say, for 30 years -- without stations overflowing or the system locking up for weeks at a time.

Besides the scenario itself, I have included a few savegames to get you started. By the time of the screenshot, things have already gotten ugly. You may start here or afresh, your choice.

changnian wrote:I want this feature in trunk.

Then start showing you're a competent developer and we might grant you "OpenTTD developer" rights so you can commit it; after it's properly tested and benchmarked ofcourse.

This patch would be great for my games. I use the street traffic AI, so there is automobile traffic. And with Cargodist, I need to use road vehicles to service passengers and mail in city centers, and to deliver goods (very realistic.)
I have the usual problem where an AI has a street blocked, and my RVs want to use it. I order a blocked vehicle to turn around, and it goes right back to the end of the queue.
Really looking forward to testing this one.

Rubidium wrote:... start showing you're a competent developer and we might grant you "OpenTTD developer" rights...

Are you serious? I've offered my skills as a graphics designer but this is not developing software. I have never pretended to be a competent (software) developer of any kind; I'm an old hardware dog. I am quite busy pushing ahead with a couple of Perl projects but I intend them as a route to competence not the result of it. The most aggressive claim I'll make (in this direction) is that, as a longtime professional in a field where "errors" can require a fire extinguisher and a call to the parts house, I exercise somewhat more discipline than the average software developer.

I have no aspiration to be an "OpenTTD developer". I suspect you guys are fooling with Python and I have enough on my plate learning Perl. As for mastering the various schemes private to OpenTTD, well.

You appear to be suffering from what I call Wikipedia Syndrome, in which the existence of a user class is denied or ignored. All persons are defined to be developers -- competent, incompetent, aspiring, hopeful, useless or even destructive; the FOSS project is open to all; so there are no mere users. Don't complain about the poorly written article; Edit this page. Within the mindset of this syndrome, the standard response to any comment is Why don't you fix it? with an implied if you think you're so smart you miserable noob.

Well. Meet your user. Incidentally, have you had any luck with the Harrisburg Transit challenge?

Terkhen wrote:There has been a lot of changes to the pathfinder code in trunk lately. As a result the patch had a lot of rejects, but they were easy to solve (mostly related to the addition of new penalties to YAPF and NPF and a reorganization of the pathfinder code files). Here is a version updated to r18429.

Small question - what is required to marge the patch with trunk?

Kogut wrote:Small question - what is required to marge the patch with trunk?

In my case, a basic grasp of how the pathfinder works before I do anything pathfinder related. I reckon that performance issues and general usefulness must be taken into account, for example.

changnian: You might want to read your original post again in order to understand the reaction to it.