News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Feedback from the online game

Started by AP, November 22, 2012, 08:20:17 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AP

Hi All

Thought I'd start a feedback thread, as I couldn't see one.


       
  • Excellent heightmap. Really like it! Any chance of an upload of the jpg / settings used?
  • Industry density appears off by a factor of 5-10x. The industrial revolution was fueled by industry, and yet the map is set up and being played as essentially a passenger network, which is not what the vehicles of the time are for (we're using cargo ships as ferries!). Each town needs 2-3 industries (or what do all the people do!).
  • Balancing for passengers is very tough, tougher now than in the previous versions (which took some getting used to), and I can't put my finger on why, though I have a couple of guesses, as below:
  • Is the maintenance on things like coaching inns set too high. Given how cheap the staging posts are, and how low the revenues are?
Other thoughts

       
  • Refunds: I'm becoming more concerned/adverse to these, the more I see the huge impact they have. Why do my lines refund passengers at all? I mean, if my employees know I have 200 berths sailing each day, why are they selling 500 and refunding 300? Why are they doing that even to passengers who aren't even mine? Refunds assume an idea of through-ticketing, which just doesn't tally with what I know of that era. I rather suspect if thousands of people decended on one seaport, they'd either wait for a berth or give up and go home - at their own cost (and paying for a another journey), not seeking a refund from the original turnpike operator.
  • There isn't a sea-going passenger (only) ship in the early era. Which may be right and proper, but it makes it imperative there's sufficient industry to allow ships to run 'full' with their real cargo.
Hope some of the above helps. ;D

ӔO

map #645
W-E: 2048
N-S: 1664
Water level: -2
Mountain height: 270-300
Map roughness: 5-6

more here: http://forum.simutrans.com/index.php?topic=8710.0


The refunds are quite disastrous, yes. There needs to be a slight change in how it's handled.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

asaphxiix

I find that refunds are very light weight in this game compared to previous online games I hosted, which is nice. Maybe 'avoid overcrowding' is off?

Also I think that rebalancing settings towards more local trips and less long distance trips can be very helpful on this matter, and make connecting between networks much easier, as they will be less dependent on one another while connected (the 'domino effect').

Also James, can you tell us a bit about game settings in this game? economy, routing pax etc.?

AP

But the premise of refunds is to refund passengers who start a journey but cannot complete it, correct? So my question is, why are passengers starting a journey without a through ticket to allow them to complete it. Why are 500 people daily trying to take a journey which has a bottleneck which only allows 200 daily through.

Refunds in real life occur when something unexpected causes an unforeseen delay. But we're talking about refunds for when an entirely foreseen product of the established schedule occurs exactly as prescribed.

It gives a false reading, for a passenger to generate profit over the first half of the network, then be refunded when they get to the bottleneck, surely?

asaphxiix

i agree that it is not ideal, but in general I wouldn't pass on it, it gives you a real incentive (perhaps too much incentive) to really work and optimize your network, it's very challenging indeed. I just think the impact is a bit too harsh. Also, I assume it wouldn't be practical in terms of the game engine and how it works to try to reserve tickets for a whole journey, but that may be an interesting option.

I do think we need a better monitor for refunds - since the impact is so great, we need to be constantly aware of it, even with a pop up alert. Currently you have to go line by line in the line info window.

Also, IRL when I go to another town using several transport lines, I buy each ticket when I get on each bus (I live in a 2.5nd world country, very small as well). If I get to the last bus line and it's too busy and I can't get on it (which happens way more often than it should), I would be very lucky to get an apology even, but a refund is what I deserve.

AP

Since passenger flows are calculated, can they be predited? Can we get told where refunds / overcrowding will occur before it occurs? Ie which routes to put more vehicles on?

ӔO

I have suggest passengers be simply discarded from the system upon the first refund in a different thread.

I think it would be nice if the game could give a notification when an imminent or massive refund occurs.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

#7
Thank you for all the feedback - this is most helpful. Firstly, as to industry, I agree that there needs to be more. I forgot to check this when I first put the map online, unfortunately. I am making myself a checklist for setting up online games to try to make sure that I don't forget again.

As to staging inns, I have reduced the maintenance cost for these for the next version of the pakset (albeit concomitantly increased the construction cost) on the basis that they were able to generate revenue to offset their cost by selling food and drink.

On passenger balancing, this might be an effect of adjusted passenger revenues: the per kilometre revenue is now higher for shorter journeys in accordance with the fare stages feature. This is intended to be realistic, and should help to reduce the differential between the revenues of short and long distance transport, which was formerly too high.

On the percentage of local passengers to long distance passengers, this has increased significantly in 0.8.4 compared to 0.8.3. In 0.8.3, the percentages were:

Local: 38%
Mid-range: 35%
Long-distance: 27%

In 0.8.4, the percentages are:

Local: 58%
Mid-range: 28%
Long-distance: 14%

Do people think that these need adjusting further? I should be interested in feedback on this aspect of things.

As to refunds, this is a difficult area. Firstly, where are people finding that refunds are occurring in this game?

Refunds were adjusted for 0.8.3, I think, so that the passenger maximum wait (passenger_max_wait) setting is now 19440 minutes (that is 324 hours, or 13.5 days). This means that refunds only occur if (1) passengers have travelled to an interchange stop; and (2) passengers then have to wait for 13.5 days to board their next transport. This waiting time would be taken into account in calculating their route, so it is unlikely that passengers would take a route that involves this level of waiting in the first place (unless the congestion/failure took place after the route was calculated). This is intended to ensure that the refund mechanism is used only exceptionally and that the main mechanism for control of overcrowding is the journey time tolerance feature. If people are experiencing many refunds, there may be something wrong with the implementation rather than the design, although I have not seen any bug reports on refunds. Does the way in which I have described it above appear to be how things are actually working, or does there appear to be some variance?


Edit: I should note that refunds are also activated if "avoid_overcrowding" is enabled when passengers are offloaded at an overcrowded transfer stop, but "avoid_overcrowding" is not enabled by default in 0.8.4, and is not enabled in the Bridgewater-Brunel game.

Edit 2: I seem to have forgotten exactly how refunds work: apologies. From simuconf.tab:

Quote
# This setting gives the maximum time that passengers are prepared to wait for their
# transport. The setting is divided by speed bonus value to get the number of minutes.
# In pak128.Britain and pak128, the default speed bonus value for passengers is 18. So,
# at the default wait time of 2,700, the maximum time that passengers are prepared to
# wait is 2,700 / 18 = 150 minutes, or two and a half hours.
#
# The same applies for other sorts of goods: for example, the speed bonus value for
# mail is 15. So, with a passenger_max_wait of 2700, mail would wait for 180
# minutes before being discarded.

With the value of 19,440, the maximum wait would be 1,080 minutes, or 18 hours. Further, this is subject to an additional constraint: the maximum waiting time is actually the minimum of that value and thrice the estimated journey time (subject to a limitation that, if thrice the journey time is less than 1/12th of the base time, the maximum wait time will not be less than 1/12th of the base time).

The multiplication by the speed bonus is a relic, I think, from when it was intended that all goods, not just passengers, would be subject to this maximum wait value, so that the maximum wait value would vary depending on the goods' speed bonus. It was later decided to change this to restrict it only to passengers on the basis that bags of grain, churns of milk and sacks of mail could not very well go and get a taxi part-way through their journey.

I wonder now whether this division by the speed bonus is now an unnecessary relic and should be removed so that it is easier to set and understand the maximum waiting time precisely. The thrice journey time restriction ought to remain, I think, but I should be interested in views on that also.

On another matter, I have found and fixed a bug on the 10.x branch relating to the correct recording of waiting times for discarded passengers, which should have the effect of ensuring that the waiting times are correctly recorded, discouraging passengers from using overcrowded routes.

Edit 3: Hmm - another error in my recollection of how the code works: this was never restricted just to passengers, presumably because the ultimate problem that this was intended to solve, being the piling up of infinite numbers of goods at crowded stations, is not limited to passengers, and goods can just be dumped, or go off. The speed bonus thing looks rather less like a relic now.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.