Skip to main content ↑ ↓

Show Posts

This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.

Messages - Carl

2
Simutrans Gaming Discussion / Re: Giving Life to City Industry
An interesting idea.

I would have thought there aren't very many goods which are distributed entirely by delivery -- most goods are distributed centrally, i.e. by users coming to pick them up (think food from supermarkets, etc.) So mostly this can be simulated with city industries that consume goods but don't produce any. Once again, think of the supermarket in pak64: this consumes various goods (canned food, etc) but the ****umption is that customers will come to the supermarket to collect these.

Many of the realistic functions you're describing could, I think, be simulated by having more end-user industries in cities using the existing functionality. As it happens, I'm making a few new such industries for the next version of pak64.experimental, to simulate just this sort of thing.

However, there are disadvantages to this. Industries pop up pretty randomly and their appearance can't be controlled nearly as nicely as (for example) attractions can. So if I make a "office" as a factory building to consume paper, there's no telling when or where it will show up. I'd love to be able to do one of the following things:

a) Specify "build_time" parameters for some city factories, so as to better control when and where they appear

or

b) Have non-factory buildings (which can be controlled in the above way) consume goods


I take it that (b) isn't too far from your thoughts, colonyan.

3
Simutrans-Extended development / "Any free platform" in pak64 and Britain-Ex
I usually run Experimental (8.2) with pak64 but today tried out pak128.Britain.Ex for the first time. In playing about with the Intro screen game I was surprised to see that, at a multi-platform station, trains don't just wait for their ****igned platform to be free -- they will go to another accessible platform if it's free. This doesn't happen in pak64 experimental, which is why I was surprised -- I wouldn't have thought this would be a pak-dependent feature. It was a pleasant surprise, though, because this feature is one thing I've really missed since switching from OpenTTD.

Is there any way to transfer this setting to my pak64 game? If it's merely a matter of one of the pak-specific files I wouldn't be surprised if it could be transferred in some way...
4
Simutrans-Extended development / Re: How (not) to choose a route
I actually do this myself when I travel between Nottingham and Leeds. Changing at Chesterfield saves around fifteen minutes on most journeys, despite the fact that there is a direct train. But if it only saved five minutes, then I doubt I would bother changing -- because the connecting train is five minutes late as often as it is on time. This kind of reason is why I favour the five minute wait minimum.
5
Simutrans-Extended development / Re: How (not) to choose a route
Interesting, thanks. I have two thoughts:

1. Even on the Tube, many transfers take longer than two minutes (as anyone who's had to change at King's Cross St Pancras, especially, will attest!). Normally it takes two minutes just to get from platform to platform, and (say) an average of two minutes to wait for the next train. So it looks as if one should usually budget for at least four minutes for a change on the Tube.

2. On most urban journeys a bus is *significantly* slower than urban rail, so I don't think a "five minute rule" would result in very many odd results. I take it that the extreme case is the very short journey. Say you want to go two stops on the tube with one change (i.e. one stop, change, one stop). That's two minutes' travelling time, but on my transfer rule the p****enger would budget for seven minutes overall. A bus would only beat this if it could get there in six minutes or less. But even if the transfer only takes two minutes, rather than five, the bus has only taken two minutes extra. On longer journeys I think this won't be an issue at all -- given two points in London, the difference between the time it takes to cover that ground by bus on the one hand and by tube on the other hand is normally *far* more than five minutes.
6
Simutrans-Extended development / Re: How (not) to choose a route
No problem, and thanks for humouring me in my ignorance -- I wish I was in a position to make informed comments about these features rather than just stabbing in the dark at what might be underlying the game's behaviour! But alas, my talents lie elsewhere than programming... :-)

It's good to hear that this feature is already coded into the game. I think five minutes could be a better value than two for the sake of route calculation. Not only would this eliminate some of the undesirable behaviour I described before, but it would also be a better across-the-board compromise between small stations (where it is feasible to transfer in only two minutes) and large stations (where you might need to allow ten minutes or more for a transfer).

8
Simutrans-Extended development / Re: How (not) to choose a route
Thanks for your response. It's a shame that a more realistic alternative would be untenable for reasons of game speed. There will always be good points and bad points about using particular variables to calculate routes; on balance, average speed seems like it will get the right results most of the time, so is the right choice.

However, today I've come across a related problem which might be more easily solved without completely altering the current framework. Here's a simplified representation of two of my lines:

Line 1: A-B-C-D-----G-H
Line 2:       C-D-E-F

Again, these are operated by the same kind of train, but Line 1 has a higher average speed because the distance between A and B is large (= a long time spent at max speed). But this means that p****engers from F to C will always change at D and wait for Line 1, even though the train they are on will take them straight to C. This always, without exception, results in them taking longer to reach their destinations than they otherwise would, because they have to wait at D for the next Line 1 train. (This behaviour is symmetric: p****engers from C to F will refuse to take the 2-train, and will instead wait for a Line 1 train to D before waiting for the next Line 2 train.)

One way to eliminate this behaviour would be to attach a penalty to transfers between trains in the route calculation process. Is there a way to penalise each transfer an extra 5 minutes, say, in addition to the additional waiting time at the transfer station? This would model two aspects of realism: Firstly, a p****enger's tendency to prefer to stay on the same train rather than change if the potential gain is small or zero. Secondly, it would model the fact that one has to allow a few minutes to transfer between trains anyway. I can't think of any unintended undesirable consequences of this off the top of my head.

Perhaps this is already programmed into the game in some degree. If so, perhaps its effect should be increased.
9
Simutrans-Extended development / How (not) to choose a route
I've been experiencing some odd behaviour on busy urban train routes, which I'll describe below. Partly this is just an exercise to help me understand the deep mechanics of the game better -- I play the game a lot, but have little knowledge of the code and calculations underlying it. But partly I hope to draw attention to some behaviour which seems to be undesirable. I hope you won't mind indulging my curiosity!

Two of my rail lines have the following stopping patterns:

Line 1: A----B----C----D----E----F----G----H
Line 2: A----B-------------------------G---------I----J----K----L

Both lines are operated by same kind of train -- think express vs. local services on the NY Subway. A is a major terminus, and B is a large suburban station which also has high traffic.

The behaviour I referred to above concerns traffic between A and B. As you'd expect, Line 2 has a higher average speed, since it runs express from B to G. But since both lines are run by the same vehicle, they take exactly the same amount of time to get from A to B. Nevertheless, p****engers travelling from A to B travel will only travel on Line 2. Oddly, this behaviour is not always symmetric -- p****engers seem to use both lines to get from B to A.

Working backwards from this, it seems that there is a close link between route selection and overall average speed of the various available lines. So p****engers are noting that Line 2 is a "faster" train when choosing how to get from A to B. But they're mistaken, since Line 2 is only faster between B and G -- there is no difference on the A->B portion of the route. Ideally, p****engers would only take into account the speed between the stations they're interested in, rather than the whole line. But I conjecture that the issue is deeper than this -- am I right in thinking that the journey times between stations are calculated using the distance and the overall average speed of the line? If p****enger decisions are based on this calculation, that would explain the above behaviour. Are my conjectures correct here? Is there any way that journey times could be calculated by something more fine-grained than overall average speed, in order to avoid anomalies like these?


Related to this, I have a question about tolerance. P****engers will always choose the quickest route to their destinations. But how far will they tolerate taking different vehicles on those routes which vary in journey time only by a very small amount? Consider the following two stopping patterns:

Line 3: A----B----C----D----E----F----G
Line 4: A----B---------D---------F----G

All other things being equal, Line 4 will have a higher average speed. But the for journeys between A and D, the difference in journey time will presumably be negligible -- Line 3 only makes one more stop. In real life I'd expect p****engers to be fairly indiscriminate between Line 3 and Line 4 when choosing a route from A to D -- a few minutes' difference is rarely taken into account into such decisions. Is this kind of tolerance modelled in Experimental, or will p****engers always choose Line 4 in this situation?


I'd be interested to hear your thoughts on these and related issues!
11
Simutrans-Extended closed bug reports / Re: M****ively negative "distance" and corresponding costs
That's interesting. I've found a similar effect as you describe -- if I saturate lines with buses, then it's difficult to make the line break even. But the loss is usually small and far less than the previous fines, and I usually chalk it up to the philosophy that almost every transport system will have a few loss-making lines which exist for the purpose of feeding the profit-making ones.

However, I think that this feature reflects two problems with the game:

1) In Experimental, p****engers are very intolerant of lines that are not *very* frequent. I find that on almost every train line I am forced to run a "subway"-style service -- a train every few minutes (or the equivalent of) -- or my p****engers will start to become unhappy and fine me. But this often results in running almost empty trains on some routes. This seems unrealistic: many real-life minor lines have a less-than-hourly service. It seems to me that such a service would be impossible to run profitably on Simutrans Experimental. To my mind, p****engers need to be more tolerant of waits. I know that this can be adjusted to a certain degree in simuconf -- but it seems to me that there is a more fundamental problem here than simply tampering with the variables.

2) As you note, the fines are very extravagant by default, resulting in huge losses for very small lines.

One more note on your use of the "tolerance" parameters to alter this. I was under the impression that those lines control whether a p****enger will embark on a journey at all -- i.e. if a local journey will take more than 90 mins then they won't even bother. Have I got this wrong?
14
Simutrans-Extended closed bug reports / Bug (8.2): industries and new towns
Standardly, each industry shows a "Workers live in:" value which features three or four nearby cities. However, in Experimental, when a new city is built, it is added to the "Workers live in:" list of every existing industry, no matter how far away that industry is from the new city.

I ****ume that this is a bug, rather than a feature? Having done some testing, it seems that the bug only arises in Experimental. (Running 8.2, pak64).
16
Simutrans-Extended closed bug reports / Re: M****ively negative "distance" and corresponding costs
Thanks!

So am I to understand that, if someone arrives at a destination and it's taken too long, that they receive a refund for their whole journey (all legs)? This would explain why the loss levels of some lines are so much higher than the revenues of those lines taken by themselves.

However, if this is the case, then the data in "Line Management" appears to be broken, since my charts display no refunds and instead seem to record this data in the "Distance" chart -- and even then, it's not clear what the metric is.

18
Simutrans-Extended closed bug reports / M****ively negative "distance" and corresponding costs
I've been playing a map (pak64) for a few (in-game) years, and have noticed an odd pattern in some of my lines. Some of my lines (mostly bus lines, but some trains too) fluctuate wildly in the profit they deliver, despite the fact that their p****enger numbers, revenue and running costs stay constant. We're talking some months a profit of -5,000 for a city bus route which runs vehicles with cheap maintenance costs. And this despite the fact that each individual convoy on the line shows a profit.

I was baffled for a while, until I noticed that the readings in the "Distance" graph in the line management box showed very odd figures which correlated with the profit and loss of these vehicles. Specifically, the "distance" value is often very, very far below zero -- in one case, -1,639,241. This seems confusing to me -- doesn't the "distance" value record how far convoys on that line have travelled? If not, how does "distance" end up negative, and how can I prevent this from happening?

Thanks in advance!
20
Simutrans-Extended development / Re: Tiny cities with huge populations
Mostly, the problems occurred when using very high median city sizes - 200,000, 400,000. But I've also noticed them occur with lower median sizes, e.g. 10,000 and 20,000.

Sometimes it seems like the game has generated a city in a particular spot, but then found that it does not have sufficient space to make a city of the size required to house so many people -- so we end up with a small-sized city with many homeless But since I have no knowledge of the generation process, this is just a hypothesis.
 
22
Simutrans-Extended development / Re: Tiny cities with huge populations
Thanks for the welcome!

To clarify, the issue was not the density per se, but rather the fact that a city measuring only 6x6 was recorded as having 450,000 inhabitants while larger and just as dense cities had lower populations.

I'm using pak64, and Renovation percentage is 12.
23
Simutrans-Extended development / Tiny cities with huge populations
I've been trying to generate maps with very large cities (several hundred thousand citizens). Sometimes when I generate these maps in Experimental I get tiny cities (by area -- say 6x6 squares) with huge populations. Sure, they are densely populated, but there are plenty of other cities on these maps with huge densely populated areas but with much smaller populations.

I'm not certain that this is specifically an Experimental issue, but I haven't encountered it in the main version. I should note that I have the new "density regulator" option in simuconf turned off.

Is this a bug? What causes it?