Transport Tycoon Forums

Sounds like some good work, any chance of a screenshot?

Screenshot

Hello,

I am very interested in this patch.

Has anyone tried to apply this patch and the 32 bit extra zoom patch together?

If not, I will try it as soon as I find some spare time. Please post if you know that it will not work - so I can save my time..

apart from the fact that i strongly discourage usage of the extra zoom patch, the chances for conflicts are fairly slim, and if they exist, they should be trivial to solve.

I think the last time I tried to get someone to compile this and the 32bpp extra zoom levels patch together it ended up not working, bunch of failed hunks or didnt compile (I believe it was pertert who tried)

Ok, thanks guys then I will try it with care ... maybe it will work to patch overlapping files separately and merge them afterwards.

I will keep you updated.

There is no option for me to play any game without EZ patch, since it is simply beautiful and sometimes even more easy to recognise ground structure for building tracks.

Is it just me or does the link graph capacity get confused(in some circumstances) when vehicle has Full Load option?

Was thinking something like capacity = number of vehicles * add per veh:(veh capacity / veh timetable roundtriptime)
but if your using full load you probably wont be using timetable, i suspect this is why the link graph capacity works on actual visits instead of theoretical ones.

full load if cargo en route? or some variant?
so as to allow accurate link capacity assessment?

please ignore this if it is not helpful.

Edit:
So i did a controlled test removing all my newgrfs and everything and am happy to report that i cannot fault it.

NekoMaster wrote:I think the last time I tried to get someone to compile this and the 32bpp extra zoom levels patch together it ended up not working, bunch of failed hunks or didnt compile (I believe it was pertert who tried)

Actually a while back I did merge those two, didn't have any issues... Everything worked just fine. But it's been a couple of months, so things might have changed...

Hello,

I have some questions about the way this patch works with cargo.

See an exemple :

When I connect a coal mine to a power plant
=> A cargo link is created, and 100% of the coal is sent to the power plant.

Now, I connect a second power plant.
=> A second cargo link is created, and coal is sent to both power plant.

Ok. But what is the interest of that ?
If I don't connect the second power plant, 100% of the coal is sent to the first one. SO, there is not any interest of connecting the second one.

So here is the idea : can't the patch pre-connect all the industries ?

So, when I connect the coal mine to the first power plant, only 50% of the coal is sent to the first power plant
If I want to bring 100% of the production of the coal station,then I must connect the second power plant.
By this way, the player is "forced" to connect all industries like it would be on real life.

This would increase game difficult and interest. Thus, it could encourage smaller trains/trucks, of very big rail network, with complex train orders (deliver coal there, there and there)

Using the production graph, I guess it would be quite simple to get the list of industries to pre-connect according the industries production/consumption.

What about this ?

there was an attempt to reduce the station rating if not all available destinations are connected, but afair that didn't work out.

That used to be the functionality, but it proved to be possible to cheat your way around it. Therfore, rating (thus cargo creation) is now influenced by the cargo waiting at the next hops.

edit: found a postby me containing the same remark

Arie- wrote:Current situation: take a coal mine, buy some trains and order a full load to improve station rating and transport all to a steel mill. Now this is how one would normally play, and does not have much to do with cargodist. Actually, you would make it only harder on yourself if you'd add more destinations as you have to balance trains better in order to have no cargo waiting in the station at the producing industry.
The old situation rewarded a player when he or she would service more industries (although servicing industries was measured in directly with its flaws).

Because of this, I still think the old situation is more like I'd (we?) like cargodist to be. I can imagine that the new situation works like a charm for passengers, for industries, where more direct connections exist, I liked the old one better. But from what I've understood, measuring served industries was to tricky. Which is too bad . Great work however. I did not experience any problems while playing (using OpenTTD_CD_g0f7d66d2_win32).

I have noticed one minor thing about cargodist which could be considered a flaw (not really a bug). In reality if one train is to deliver cargo to multiple locations the cargo is loaded in serial: ENGINE-DestX-DestX-DestX-DestY-DestY-DestY etc. Obviously for easier manipulation. Because the cargo in OpenTTD is generated in chunks consisting of cargo for all destinations it produces trains loaded quite oddly where each carriage contains cargo for all destinations. It then seems weird after first destination is serviced (see attached screenshot) when there are full and empty carriers mixed.

As this is just a aesthetic flaw it's low priority. Needless to say I can't think of any solution without changing the loading algorithm/mechanism.

It is using passenger loading patters

In a passenger train people will get on all along the train and not fill one carrige first - I agree it looks a little odd for other cargos though

Ok since this occurred in a CD build: Since when do trams crash on their own? edit:I've replayed the savegame (9 months) a few times and it does not occur again. I'm adding two savegames: the last one before and the one when I found out.

Hi fonso,

I really enjoy playing games with cargodist. However, stations becoming swamped with passengers bugs me. I decided to see if I could prevent this, and came up with a patch (attached) to be applied on top of cargodist to prevent stations (well, links) getting passengers faster than can be transported (I'll call this being overloaded) that seems to work in all the savegames I've tried it in. Having read the thread I get the impression that the effect of station ratings should accomplish this too, but it seems I'm too impatient!

Also attached is an example savegame where the difference in behaviour can be shown. If left to run as-is, the two stations in Dronborough will become overloaded. However, if run on a build with the attached patch applied and the advanced setting "Link graph > Try not to overload links" enabled, then the number of passengers and mail per outbound link will remain manageable. (Sometimes it might get quite large, but will soon start to decrease.)

I realise that an argument for the current behaviour is that it challenges the player to provide sufficient capacity for all passengers and mail to be transported, but I would like the option of a more relaxed mode of play in which the game tries to utilise the player's network as much as possible, but tries not to overload it.

There are a few issues with the patch that I've noticed so far:

* Links with very small capacities can still become overloaded. By very small I mean I've seen it happen to links with monthly capacities of fewer than 30 passengers, but doubling their capacity relieved them.

* It only acts on passengers and mail. This is because it ruined the transportation of freight by vehicles set to full load from a primary industry, and I assume the same would happen with other industries.

* When "Link graph > Try not to overload links" is enabled, it discards passengers that are added to stations whose next hop is INVALID_STATION. This is because when testing I found that stations otherwise became overloaded with these passengers.

* If passengers are generated at a station too quickly, then passenger generation at the station will stop for some time to allow for the passengers already there to be transported away. I don't mind this too much as it could be thought of as similar behaviour to tube stations being closed due to overcrowding (see http://news.bbc.co.uk/1/hi/england/london/7704113.stm for an example of this.)

If you have time, please let me know what you think of it!

EDIT

Changed the patch a little.

The simpler way to get this kind of effect would be to adjust new passenger/mail arrival at a station depending on the number of that cargo waiting. This can be done in a way to add what is effectively like a maximum cargo waiting time. How abut adjusting cargo buildup at a station with something simple like:

r=a*(1-(w/(m*a))

Where a is the monthly cargo production within the catchment, m is the maximum cargo waiting time (in months), w is the waiting cargo quantity and r is the resulting cargo recieved by the station. This equation will result in the amount of cargo waiting at the station saturating if none of the cargo if picked up for a long time. The rate of buildup of cargo slows gradually as it approaches this limit. The point of saturation depends on the quantity of cargo produced in the catchment - a station with a big catchment will have a higher saturation limit than a smaller one.

I guess it would be simple to code this to test it, and it might even be useful without cargodist on too

Zephyris wrote:The simpler way to get this kind of effect would be to adjust new passenger/mail arrival at a station depending on the number of that cargo waiting. This can be done in a way to add what is effectively like a maximum cargo waiting time. How abut adjusting cargo buildup at a station with something simple like:

r=a*(1-(w/(m*a))

Where a is the monthly cargo production within the catchment, m is the maximum cargo waiting time (in months), w is the waiting cargo quantity and r is the resulting cargo recieved by the station. This equation will result in the amount of cargo waiting at the station saturating if none of the cargo if picked up for a long time. The rate of buildup of cargo slows gradually as it approaches this limit. The point of saturation depends on the quantity of cargo produced in the catchment - a station with a big catchment will have a higher saturation limit than a smaller one.

That formula looks nice, but it doesn't take into account the capacity of all paths from the station - the overall number of passengers at a station shouldn't matter as long as each the number of passengers to each possible next hop eventually becomes small (but sooner than waiting for station ratings to decrease and take effect.) I didn't state this in my original post - sorry!

One could imagine a station with N different next hops, and there never being significantly fewer than N*(average capacity of trains) passengers at this station would be perfectly acceptable, with many passengers for each next hop except for ones that have just had a train depart for them.

It also doesn't seem to take into account that lots of passengers might transfer at the station - so w/m might always be greater than a due to passengers continually being dropped off at the station for transfer, so the station's town would never generate any passengers for the station, which is undesirable.

Hey,

every now and then I let some trains unload at the terminal stop, drive on a side track, wait there, drive back to the station and continue from there. My orders are in the terminal station "unload and leave empty" and "no loading" in the side-track-"station". So no passenger is allowed to travel between the main station and the side track.

The problem is, that some passengers want to do that... Nobody wants to board at the side track but some people from other cities want to travel to the side-track.
This example has been done with the latest version (ge4cd8dc3-cd)

Not quite sure what the aim is here, but you can issue an order to go to the depot (just click on it after Go To) which would remove the need for the station.

Not quite sure what the aim is here, but you can issue an order to go to the depot (just click on it after Go To) which would remove the need for the station.

The depot in the screenshot is not a depot but a station.
Dwight_K._Schrute does not show the timetable for his train but according to his recent posts the train is supposed to wait there for a while.
You can not (yet) tell a train how long to stay in a depot (although that would be a useful option).

@Dwight_K._Schrute:
You found a corner case? Well done.
Assuming that train 1 is the only train going to "Waiting Place" there should be no passengers wanting to go there from "Augsburg".