somewhat hard to describe, but if player 1 owns a loop line, and player 2 owns a line that goes through the center, player 1 will receive a high influx of pax, but will be paid poorly.
uses pak brit ex
http://dl.dropbox.com/u/17111233/loop_ex.sve
There's a lot going on in that game -- which loop line exactly is underperforming?
Do you have a saved version of this before anything was built, this map looks like a good challenge, would like to see what I could do with it.
ah yes, company AEO's 0001 and 0002 lines.
this map is the one currently in play on james' server.
The big problem with long loop lines in Experimental is that passengers will happily travel 3/4 of the way around on a train headed "in the wrong direction", and you only get paid for the 1/4 (shortest distance).
You can also mitigate the preference to trains filling with local passengers by, for example, making an underground shuttle calling at all five stations between Elfield St. Katherine's and Elfield Markfield... and then having mainline train routes 0001 and 0002 stop only at the main station (Elfiend Kirkbridge Way) plus either St. Katherine's or Markfield -- whichever is in the "up" or inbound direction for that route. That's as close as we can come currently to "stops for departing passengers only".
Any particular reason why your system does not haul mail?
Hello
Quote from: wlindley on January 24, 2012, 02:52:04 PM
The big problem with long loop lines in Experimental is that passengers will happily travel 3/4 of the way around on a train headed "in the wrong direction", and you only get paid for the 1/4 (shortest distance).
I thought that passengers use the line taking the bus in the direction of the shortest, it seemed to me that "Sim-Exp" actually uses this method. In fact, I remember that passengers took the bus only in the direction faster, but at this point I would not be wrong
James can you help?
Giuseppe
@windley
there is no particular reason the network doesn't haul mail. I guess I like to keep it simple.
There was a problem with loop lines (as wlindley describes) in an older 10.x version, but the release notes of a later version made me think it had been fixed. I haven't gotten around to testing this yet, though...
I am just about to look into this issue. AEO - when you reported it in chat, you said that it was an issue with passengers who had transferred to a player's station by walking did not then generate any revenue - is that correct? Edit: Having tested this, I cannot reproduce the issue if I have understood it correctly.
Giuseppe - you are correct that in Experimental, passengers/goods will take the fastest route, so will not be inclined to go the wrong way around a loop line. This was more of an issue for Standard, but I think even in Standard this is less of an issue now with the intermediate stops feature in routing. The being paid for the straight line distance between origin and destination is also a Standard specific feature not reproduced in Experimental.
@james
I think that was the gist of it.
It just seemed odd that a line that full was always running in the negative.
Is there any other reason that you localised this to passengers transferring by foot, rather than, say, a balance issue? Short distance traffic generates low revenues generally.
in that game, there were a lot of passenger transfers going on between the 4 companies there, so I had figured, "maybe there is something going on".
Ah. In an isolated test, checking just this feature, that was not an issue.
are those two lince counterrotating on the same loop, or are those two bi-directional loop lines?
the first case does not balance well in simutrans. (that's where, i think, the strength of the reverse schedule code lies)
ah yes, that might be another bug, but it seems that upon the save/load routine, convoys will ignore signals and ignore shortest route to station when reverse schedule is in effect.
I typically don't like using the reverse for trains, because those two cause jams and locks
it is very very finicky. but when set up properly it works like a charm. It breaks down when loading, that's a long known but not identifiable bug. (the solution is to have some built in re-ordering mechanism.
Perhaps the platform searching for the reverse route feature needs an overhaul, we (i) should test it and think a bit on improving.
Quote from: AEO on January 29, 2012, 03:21:45 AM...convoys will ignore signals and ignore shortest route to station when reverse schedule is in effect...
Can you elaborate on what you mean by this?
@james
they seem to ignore presignal and long block signals occasionally, which sometimes caused a jam on some of my branch lines.
occasionally, on dustNtrans company, they will ignore choose platform signal when a two-way signal is on the platform.
it seems to happen on save/load
Hmm - I suspect that these errors may originate from Standard; does anyone else know whether those can be reproduced there?