News:

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

Alternate routes

Started by Fabio, January 06, 2009, 01:52:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

isidoro

Quote from: jamespetts on January 09, 2009, 12:07:22 PM
[...]
Do you think that you could add to your QoS metric the fact of obsolete vehicles on the line?
[...]
It might work particularly well if the station radius coverage was increased from 2 to 3 tiles, or, even better
[...]
It is simple to change the QoS function to whatever, provided you have the necessary data to calculate it at hand.  There is a parameter in config files to specify a global coverage radius, if I remember well.  Now train stations do have more coverage than a bus shelter, don't they?

Quote from: fabio on January 09, 2009, 12:57:29 PM
[...] but i can't see if my main point is still considered: can passengers have different needs/tastes/profiles and choose different routes (also with the same company)?

With the patch I'm programming, that's not possible.  There had to be different "kinds" of passengers and, seeing how that is programmed, I believe that would be complicated (maybe I'm wrong).

jamespetts

I do know about the ability to change station coverage radius in simuconf.tab - but that applies to all stations equally. It would be good to have a station radius coverage specified in the .dat file for each individual type of station. It would also be useful to have car parks interacting with the system of private cars described here so that passengers could actually drive to the station/airport and complete their journey by public transport, although that would require the preferences to be assessed for each hop of the journey, rather than for the journey as a whole; the computational resources would have to be considered.

It would not be too hard in theory also to have different types of passengers: a random chance of each of three types could be assigned in simuconf.tab (or even from a rolling date system as in speedbonus.tab), and then all put into an array of three numbers, and processed individually. The question is whether having to do three times as many calculations for each passenger trip will create excessive CPU load, and whether the feature is one that will work well in practice and make the coding time worthwhile. I am not entirely convinced that it would work well, but am open to being convinced, since I have not thought about the matter in depth yet. Fabio, perhaps you could explain further what this would add in practical terms to the interesting decisions that the player has to make that make the game fun over and above a catering level?
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.

Lodovico

If you will have different types of passengers in the same way as different types of cargo are now,
then cannot be more any additional calculations ...

jamespetts

There would be additional calculations, just as there would be if you added different types of cargo to the same factories, each with their own routing preferences. However, that it takes some additional resources is not by itself a reason to reject it - the question is whether it noticably impacts on performance, and, if so, whether the impact is great enough to outweigh any benefit conferred by the feature.
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.

Fabio

Quote from: jamespetts on January 09, 2009, 11:49:59 PMFabio, perhaps you could explain further what this would add in practical terms to the interesting decisions that the player has to make that make the game fun over and above a catering level?

1. it would add realism: in RL there are always two or more different ways to get from city A to city B, both are used, if pretty much equivalent, and they can be both profitable. It's highly unrealistic that from A to B all the passenger will choose ONE and THE SAME route.

2. if there is already a route (e.g. a train) going from city A to city B, the player  could add a second route (e.g. a flight) without closing or making unproffitable the old route.

3. the player could/should diversify its offer to match the demand of different targets of passengers: if the connection has a fare price too high, it will attract only business, if it's cheap but slow it won't attract business at all.

4. it should go along with catering level: a higher level would be necessary to attract higher level passengers, but it would discourage low level passenger because of its fare price.

isidoro

I wouldn't say routes, since that is confusing from the program viewpoint.  If you have two towns A and B and two means of transport to carry passengers from the first to the second, there is only a route, but two connections from the program viewpoint.

If, on the other hand, you have two other towns/stations C, D, and two possibilities A-C-B and A-D-B, there would be two possible routes.

What is what you want, the first or the second possibility?  My patch works only on the first, not routing at all.  Playing too much with routes needs a lot of power of computation for the simulation.

Fabio

Let me call them "alternatives".

1st alternative:
Town A, central stop (bus)
Town A, railways station (train)
Town B, railways station (bus)
Town B, east stop (destination)

2nd alternative:
Town A, central stop (bus)
Town A, AIRPORT (airplane)
Town B, AIRPORT (bus)
Town B, east stop (destination)

is this what you mean?

isidoro

My patch won't do that.  Your "alternatives" involve routing.  My patch acts once the route has been decided.  In your example, it would work if you have "mixed stations":  Central station in A has airport and train.  Central station in B has airport and train.  There is a connection by air and a connection by train between both stations.  Depending on QoS of vehicles arriving, passengers would choose one or another.  And the same even if there are only connections of one type.

Here's the improved version of the patch.  It wasn't so difficult after all.  Now, the QoS and time waiting is measured in a station per connection.  You can see the average time of vehicles arriving at the station per destination in the details window of the station.  My main concern is performance.  I've played with it and didn't notice the simulation slower, though.

The above restrictions about savegames apply.


jamespetts

I am a little confused by the way in which price is handled: the calculated price per kilometre is taken as a factor that the passengers take into account when deciding which route to use; but is the calculated price per kilometre not supposed itself to be dependant on the desirability of that route? In other words, there would now be two conflicting systems for assessing desirability of a route, one assessing it partly by the inverse of the measure used by the other? That might create some odd outcomes.

I suggest that "price" in the sense used in this patch not be taken into account at all, since price is simply a measure by the game of the quality of service (mainly, the speed bonus).  It would make sense if the player could have some direct influence on the price (setting it "low", "medium" or "high" per line), but it makes no sense to penalise a player's route for being a high-priced one when the player has no control over that price, and where the price is high because the game, by design, assumes that people are willing to pay more to travel on the faster transport. If now there is a possibility that people are not willing to pay more to travel on the faster transport, then the player should have the option of providing the faster transport and charging people less to use it.

Also, I am not sure about using the average speed of a particular convoy: the individual convoy in question might have happened to have been stuck behind a signal or in a traffic jam a great deal for the last few months, which would have no effect on its overall service quality. I still suggest that a per line system would more accurately reflect a realistic assessment of passenger choice.

One question: I am not sure what the reason is for using the average speed in the calculation of price - can you throw some light on that? I am not sure how that interacts with the speed bonus from file system.

However, I do like the idea of having a standardised QoS metric for a station, because that QoS metric can then be fed into other calculations for passengers deciding which stations to use. Might it be worthwhile, perhaps, to have the number per station per line, and also a general metric per line, and a getter method to return the overall average per station?

This is certainly promising, though, and heading in the right direction. It is most encouraging also that you did not notice any performance degradation.
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.

isidoro

Lots of questions...  I'll try to do my best:

  • In order to compare QoSs, price per km is obligued.  Otherwise, long distance routes would be penalized
  • The rationale of ticket price is this:  when a convoi arrives at destination, the player is paid an amount of money per km per passenger transported.  That amount comes from ticket prices.
  • Presently, there is not a possibility for the player to choose a ticket price (see last item), maybe because it was considered more micromanagement and somewhat more of a business game rather than a transport game, I guess.  There are no shares, etc. as well.  The player can influence the ticket price by choosing different vehicles, though.
  • I agree with you that ticket alone is not a good measure at all.  But quality is measured as speed/price.  Passengers can choose a more expensive vehicle if it will carry them faster enough.
  • On long enough statistics, signals or other unexpected events compensate.  If not, then the passenger should know that certain vehicles happen to be slower because they share track with the Cincinnati express.  Besides, as lines don't have all vehicles of the same kind, it would also be unfair to consider all the same.  Nevertheless, one can easily get an average per line from averages per vehicle and show that info to the player in the line information window.
  • The ticket price depends on the characteristics of a kind of vehicles alone.  Average speed is a measure of performance.  You can have two equal airplanes.  Both will have equal ticket price per km.  However, one performs better, then gets more passengers ans the other, worse, so gets less.

isidoro

Small update to deal with separate station capacities now in trunk...