Cargo Distribution

[audigex]

"Realistically" people do tend to travel round the town, but does it not take a little of the fun out of the game if you spend your whole life expanding local bus routes rather than making nice intercity links?

There's "real-realism" and "game-realism" - making it actually realistic as opposed to making it realistic within the scope of the game.

[jub]

I personally would prefer more passengers going between stations within the city and less between cities. Currently I have intercity links quite overloaded. Someone prefers current state, someone would like a change.

I would appreciate some setting where I would be able to tweak amount of passengers going within (between) cities.

[audigex]

Fair point, Fonso - would it be possible to have some sort of slider/setting to change between preferring intercity and local travel? Maybe a 1-5 scale (1 being almost totally local, 5 almost totally intercity, using local only where it's used as a feeder), to cater to more people's needs?

[kvtb]

it is currently almost impossible to handle traffic between two large stations in the same city
E.g., consider a city with 30000 residents, and three stations.
The stations itself are not directly connected (Paris-style). However, with a very large detour it is possible to travel between the three stations. The detour-traffic becomes so large, it is almost impossible to handle, and setting up a local bus/tram line does not have a lot effect.

Although it's true that most people travel within city borders, they also travel with other vehicles, like bicycle, car, or by foot. That is an argument to limit within-city traffic.


For those interested, I'll post a savegame soon, and challenge those who like the current behaviour, to deal with all traffic demand (without demolishing the whole city)

[fonso]

In effect there are several people here with opposing problems:

• some want demands on short distances to increase even more
• some want demands on long distances to increase and demands on short distances to decrease
• some want the size of stations to have less influence on the demand
• probably there are some who strictly oppose the idea that the size should have less influence

I'll think of modifications to the demand functions so that the influences of distance and size become configurable and the demand function in general becomes more accurate. You'll hear about the result. Unfortunately at the moment, there are two other problems to be solved:

• The smallmap needs fixing and now that I've started it I'll try to finish it.
• Cargo payment is extremely inaccurate. No one has noticed yet, but that's probably the reason why your profits take such a big hit. I'll have to redo the whole payment scheme and have cargo paid after being unloaded. Of course you'll still get an indicator of what is being paid while it is unloaded. In sum, that is a lot of work.

So, once again, be patient. I won't have too much time in the next weeks.

[andythenorth]

I'll think of modifications to the demand functions so that the influences of distance and size become configurable and the demand function in general becomes more accurate.

Hi Fonso,

Looking ahead (and appreciate it may be a _long_ way ahead)...are the above something that would be available for control by nfo?

The purpose would be to allow the creation of newgrfs that modify cargo economy, for example by modifying demand (lets imagine that the criteria for how to modify these are arbitrary...for now).

cheers,

Andy

[NCarlson]

it is currently almost impossible to handle traffic between two large stations in the same city
E.g., consider a city with 30000 residents, and three stations.
The stations itself are not directly connected (Paris-style). However, with a very large detour it is possible to travel between the three stations. The detour-traffic becomes so large, it is almost impossible to handle, and setting up a local bus/tram line does not have a lot effect.

Although it's true that most people travel within city borders, they also travel with other vehicles, like bicycle, car, or by foot. That is an argument to limit within-city traffic.


For those interested, I'll post a savegame soon, and challenge those who like the current behaviour, to deal with all traffic demand (without demolishing the whole city)

I suspect that the real problem is in grfx set balance here. TTD is pretty much missing a good option for high capacity inner city traffic; we need subways. As long as the only really high capacity system is surface rail requiring demolition this is going to be a problem IMO. What I'd really like to see is another road derivitive (like trams; two way on one tile, and handled like roads for coding purposes) line type that has slow speed, high cost and no ability to cross other line types at grade but has conventional railroad equivalent capacity multi car trains stopping at multi tile stations. It's really a whole seperate project to implement and balance (and figure out if it actually needs engine changes to work) but that really my main point, we're looking at a game rather than patch flaw.

PS: I know that we're still a long way from the true underground construction needed to make this work like it really should, but I suspect it would be useful in a game with pax destinations now.

[audigex]

Sounds good - we all know how much work this sort of cargo routing system is, we can see the others fallen by the wayside. The fact you're accepting more requests says a lot about you

Configurable is usually a good idea, as so many people have a different game style. Personally, I hate micro-managing everything and local routes, but there are so many other ways to play.

[TrueTenacity]

Is there a playable build of this system?

Would love to play with cargo destinations...

[fonso]

Looking ahead (and appreciate it may be a _long_ way ahead)...are the above something that would be available for control by nfo?

The purpose would be to allow the creation of newgrfs that modify cargo economy, for example by modifying demand (lets imagine that the criteria for how to modify these are arbitrary...for now).

You don't want to write a demand function in nfo. That's just sick. nfo doesn't have proper loop statement, it doesn't allow recursion and it generally is an awful programming language. And don't get me started about callbacks ... We could talk about certain parts of the algorithm being scriptable in squirrel, but that's far away and for now all configuration is to be made by the user as simple configuration options.

If you insist on nfo maybe a general configuration-to-nfo bridge could be possible. You'd basically write parts of openttd.cfg as grf which would then provide some consistent set of non-editable configuration settings for something. However, that's a different project altogether.

[andythenorth]

You don't want to write a demand function in nfo.

Worth knowing, thanks.

That's just sick. nfo doesn't have proper loop statement, it doesn't allow recursion and it generally is an awful programming language.

I am starting to find nfo elegant. In a strange way. A very strange way.

[Eddi]

NFO certainly is elegant in its own twisted ways, but not as a general purpose programming language.

providing a function in squirrel is probably problematic, as you would have to distribute that to all clients.

[Roujin]

[...]Cargo payment is extremely inaccurate. No one has noticed yet, but that's probably the reason why your profits take such a big hit. I'll have to redo the whole payment scheme and have cargo paid after being unloaded.[...]

If you find a nice solution for that (cargo paid after being unloaded) also applicable to vanilla OpenTTD, could you make it available as a seperate patch? I reckon it might have good chances for trunk inclusion, as it has already been noticed as a loophole in OpenTTD that has to be stuffed (but nobody has attempted yet to do so afaik). Thanks to a certain "rondje om de kerk"

[DaleStan]

You don't want to write a demand function in nfo. That's just sick. nfo doesn't have proper loop statement, it doesn't allow recursion

Yet.

An operator could be added to variational 2 that would be something like "if (right) return CallContaining2(); else return left;". Alternatively, 'left' and 'right' could be swapped. I remember enough CS[0] theory to know that recursion is equivalent to looping, and there would be a relatively simple trap for infinite loops: allocate $SMALL_NUM stack frames (32 frames? 4KB of stack?), and if it exceeds that, treat it as if one of the variables referenced did not exist, and snap to the first option. (GRF coders would almost certainly appreciate an option to make this dump the GRF stack.)
Combining this with procedure calls would allow loops anywhere in the code path; just call $LOOPING_VAR2 when necessary.

To make this even nicer[1], add either a new variable for stack-local store (7B) and another operator to write to that memory range, or define that some of the GRF registers are stack-local. "Some" could be hard-coded or a GRF-supplied per-call value.

This does not make NFO a good language for programming loops, but its basic design as a bytecode makes it (likely) faster to machine parse than squirrel. With things that may need to be executed every tick, or even multiple times per tick, this is a definite plus.

[0] Not Chris Sawyer.
[1] Relatively speaking.

That said, ...

providing a function in squirrel is probably problematic, as you would have to distribute that to all clients.

As these are not preexisting, you could build in a redistribution system, so clients could download the funcs from the server. If the redistribution system exists before the things that it could redistribute, there is no existing copyright to conflict with, and all new works can readily be assumed to be licensed permissively enough to allow the redistribution to work.

[Eddi]

That said, ...

providing a function in squirrel is probably problematic, as you would have to distribute that to all clients.

As these are not preexisting, you could build in a redistribution system, so clients could download the funcs from the server. If the redistribution system exists before the things that it could redistribute, there is no existing copyright to conflict with, and all new works can readily be assumed to be licensed permissively enough to allow the redistribution to work.

well, i was speaking about the technical aspect of implementing such a system, not the legal implications. besides, the german copyright law allows "temporary reproduction, that is an integral part of an otherwise legal use, and has no economical value by itself" without permission and payment (§44a UrhG).

this includes stuff like copying data from HD to RAM for playback, or saving in the browser cache for viewing a website. that would also extend to GRFs, as long as the copy is meant to be temporary (e.g. deleted after disconnecting from a network game)

[fonso]

[...]That's just sick.[...]

An operator could be added to variational 2 that would be something like "if (right) return CallContaining2(); else return left;". [...]
To make this even nicer[1], add either a new variable for stack-local store (7B) and another operator to write to that memory range, or define that some of the GRF registers are stack-local. "Some" could be hard-coded or a GRF-supplied per-call value. [...]

Do I have to add anything? OK, I will add some more redundancy:
This is an incredibly baroque way to implement recursion. And the demand function isn't run very often. Furthermore it is deferred to its own thread, so we definitely don't have a performance problem here. We can afford to use a programming language.

[swifty]

Yay, so many changes incoming Anyway, I finally got to play a proper game instead of synthetic testing, and the passenger demands really seem to smooth out after the stations are up for some time and there are more of them, and it looks quite "natural". But yeah, I also prefer the intercity links over local ones (within one city), simply because it's extremely hard to handle the local transport with anything else than trains, as people have already pointed out. But that's a general OpenTTD thing. I'll rather keep adding capacity to train links between cities, because that's much easier to do.
Right now I don't bother connecting my city centers to the railway hubs on the edges, because there is absolutely no way I can handle the amount of passengers going between those. Plus even a single bus station right in the city center will seem extremely important to the demand function, and will generate tons of passengers to it from the connected nodes. It seems that the only way to do local transport in the big cities now is to build a bus/tram circle route and not connect it outside (to the railway stations).

[fonso]

Building a single bus stop in the middle of a big city is stupid. It always was and cargodist only highlights the problem. Naturally the stops in the middle of a city cover most houses and attract most passsengers. Thus they are big in terms of the demand function. So you have to plan for a lot of capacity from the beginning on. Building lots of bus stops near each other helps as the passengers will be divided up among them and each stop gets smaller for the demand function. Building large stations with many bus stops helps as you can increase the capacity more easily. Building a single stop and hoping that passengers will ignore it doesn't help.

[swifty]

Yeah, I wouldn't build a single one in the city center, I just meant that one tiny station will probably attract more passengers from other nodes than the huge railway hub station on the city edge. So in theory, in order to have some chance at handling the traffic between city center and the hub, it's best to build multiple separate bus/tram stations and connect each one to hub separately (star topology, instead of circular)?

[fonso]

Yeah, I wouldn't build a single one in the city center, I just meant that one tiny station will probably attract more passengers from other nodes than the huge railway hub station on the city edge. So in theory, in order to have some chance at handling the traffic between city center and the hub, it's best to build multiple separate bus/tram stations and connect each one to hub separately (star topology, instead of circular)?

Both. The railway hub is the center of a star topology. But additionally the local stations should be connected by a circle line so that local traffic doesn't need to pass the hub. Just look at a typical metro map to see how it's done.