News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Pax unit count vs. mail unit count

Started by Sarlock, March 13, 2014, 11:37:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sarlock

A minor nuisance: passenger and mail units are significantly different in terms of the quantity generated and transported.

ie: A brig hold has 25 passengers or 250 mail.  This creates some difficulty when setting an appropriate load % for a combined pax/mail vessel.  A ship with 5 pax holds and 2 mail holds can carry 125 pax and 500 mail.  If you set this ship to 20% load, 125 mail will make the ship sail even though it may not even have any passengers yet.  Likewise, if you get 100 passengers loading on to this ship, it won't sail until it reaches 125, even though it's already almost full of passengers - and passengers are far more profitable per unit than mail is, so you want this ship to sail at this point.  I end up having ships that have 25 passengers and 100 mail, which is not terribly profitable.  If I set the load % higher, however, passengers can end up being frustrated waiting.  I want the passenger count to be the primary trigger for when a ship sails, but the mail is dominant in the equation and ends up making the primary decision.  Sometimes a ship will sail with just mail in its holds... then passengers are generated a short time later and the ship has already sailed without them.

I think reducing mail counts to be similar to passengers would be helpful to balance this off: if mail counts are reduced by a factor of 5 to 10 and revenue boosted accordingly (so that nothing is changed other than the unit counts for mail generation and transportation vehicles) it would help make it easier for the player to balance a combined mail/pax convoy.  This would allow me, in the above example, to have 5 pax holds (125 pax) and 2 mail holds (25+25=50 mail) set to a higher 30% load which would sail at 53 combined load, which is far preferable and more profitable (thus a more effective use of the vessel).

EDIT: This should probably in the pak128.Britain.Exp folder.
Current projects: Pak128 Trees, blender graphics

jamespetts

Mail and passengers were originally quite similar in numbers, but the problem is that, to get realistic quantities of mail being generated, there must be an order of magnitude distinction: the actual amount of mail generated is vastly, vastly less than the actual number of passenger journeys. We initially had mail in units of bags, but this was far too big a unit to work with the small quantities necessary for realistic representation, so I changed it to "bundles" of mail, a tenth of the volume of mail in a bag. Then, using realistic figures for the number of bags of mail that a vehicle can actually hold and multiplying by ten to get the figure for bundles, we end up with the figures that we have now. I that this creates difficulties with the percentages potentially, but I am doubtful that any vehicle carrying passengers should be set to wait for a certain load before departing in any event - apart from certain tourist rides off season, I do not think that this ever happens in real life for precisely the reason that it is a problem in Simutrans-Experimental.
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.

Sarlock

It's true... but then again, in real life, passengers don't arrive at the docks 12 hours before the ship arrives either, they know to show up at 7:30ish for the 8:00 sailing.  In Simutrans, they just show up randomly and you have to compensate for that... thus the load %.  You don't want ships taking off with 0 passengers in them... then have 100 passengers show up from a connecting line and have to wait 8 hours for the next ship.
Current projects: Pak128 Trees, blender graphics

jamespetts

Quote from: Sarlock on March 14, 2014, 12:31:18 AM
It's true... but then again, in real life, passengers don't arrive at the docks 12 hours before the ship arrives either, they know to show up at 7:30ish for the 8:00 sailing.  In Simutrans, they just show up randomly and you have to compensate for that... thus the load %.  You don't want ships taking off with 0 passengers in them... then have 100 passengers show up from a connecting line and have to wait 8 hours for the next ship.

I don't think that skewing mail to passenger generation ratios is really the solution to this, as doing so would have far-reaching implications that would make the pakset impossible to balance realistically, for mail, at least.
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.

ӔO

Scheduling so that passengers have a seamless connection reflects real life.

Although, mind you, the people who create the diagrams typically have degrees for this.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Sarlock

Quote
Although, mind you, the people who create the diagrams typically have degrees for this.

And usually more than one of them!  Players have a few minutes per day to try and perform the same task... and except for the sadistic amongst us, probably don't want to spend their entire time trying to construct and maintain detailed schedules.   ;D

But ultimately, the difference in passenger habits in Simutrans necessitates a method of dealing with them that is different than what occurs in reality.  In real life, passengers don't show up 12 hours before a scheduled sailing and then ask for refunds when the ship doesn't arrive for 12 hours... or not take the ship in the first place because they don't like the 12 hour wait.

I'm struggling a bit to deal with the pax/mail scale differential.  I've found that the easiest way to space convoys in a line out, to keep them from bunching up, is to establish a load factor at one or more stops on a line, usually one of the main terminals.  I've used scheduling in a few instances but this requires more micromanagement as it has to be calibrated when new ships are added to the line or associated lines.  Load factor also helps to keep convoys from heading out empty - when the ship is embarking on a 16 hour journey, it's nice to actually have passengers and mail on it to pay its way.  From the 1750's to 1850's, if you want to maintain good passenger counts, you need to run often, even if it means you're only running 20% full.  Passengers will refuse to even take the service, or ask for refunds if they try, if you make them wait too long in order to get your load factors up higher.  This is where the pax/mail unit scale differential causes problems - load factors will bias towards mail, sending a ship on its way when it is a certain % full even if it should wait for passengers.

I could set up separate pax and mail services, but this would require many more ships in order to maintain a good level of timely service for both (and even lower load factors) and I don't think the server would be happy with another 1000 ships :)

This might largely resolve itself by the 1850-1900 period when travel speeds increase significantly, but that's still, at 1-2 game years per day, 1-2 months away from now.

If it's too difficult to change this, we can live with it :)  I know there's a needed balancing pass for pak128.Britain.Exp so I thought it might fit in.  As always, I am more than happy to help in this respect.  I can't code, but I am pretty handy with a spreadsheet.
Current projects: Pak128 Trees, blender graphics

Vladki

What about adding the possibility to set load% separately for different cargo. If would be beneficial also for trains (mixed pax/mail and even goods).

Sent using recycled electrons.


jamespetts

The real issue, I think, is not the fact that mail is counted in "bundles", but the fact that there is so much less mail generated overall than passengers. Mail behaves differently to passengers in Experimental in that it does not refuse to be sent if it takes too long to get to its destination, although it will, like all cargo, take the quickest route. Mail thus behaves more like passengers do in Standard than like passengers do in Experimental, and is subject to a much stronger network effect, where the amount of mail carried increases exponentially as the number of buildings producing and consuming mail increases linearly. This means that, just as in reality, long distance mail transport potentially needs to have a very high capacity on highly connected networks, whereas local mail transport and mail transport generally on early/lightly connected networks need not have anything like that capacity. This, again, reflects real life. The large capacities for mail that one sees are based on the potential need to carry many bags (10x bundles) of the stuff in the case of a trunk connexion on a highly connected network. These are, in so far as it was possible to research them, the real life capacities of the vehicles. If the capacities of mail vehicles were reduced tenfold (or the amount of mail generated increased tenfold), the ability to carry very large quantities of mail on trunk routes would be lost, unrealistically.

The problem with setting percentages of capacity is different. As Vladki suggests, in theory, that can be solved by allowing different percentages for each type of load, although actually implementing that is potentially complex, and there is an extraordinarily long queue of higher priority tasks.
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.

Sarlock

If a "bundle" of mail is equivalent to 10 bags of it as it exists now (decabag?), the vessel is still carrying the same amount of mail weight and volume-wise, just 10x lower in unit count.  As it exists now, with the disparity between unit counts, the product (mail) which can afford to wait at the station is overweighting the product that can't (passengers).

Setting individual percentages would be nice, but as you say, requires yet another programming chore.  Pakset balancing could be done by someone else.
Current projects: Pak128 Trees, blender graphics

jamespetts

Ahh, the trouble is that there is nobody out there with the scores of hours needed to do pakset balancing who is also interested in doing that, sadly. As to the bundles, I think that you may misunderstand: a bundle is a tenth of a bag, not ten bags, and bundles are the current unit of mail. The volume count cannot go any lower without producing anomalies (it might take an actual house in real life several years to produce enough mail to fill a bag: scaling that to the hours/minutes scale in Simutrans-Experimental, one year of hours (assuming 16 active hours per day) is 5,840: dividing that by 6.4 (the number of hours per Simutrans game month) produces 912.5 months, or 76 Simutrans game years. Obviously, a building cannot produce a unit of mail once every 76 years, hence the unit sizes must be smaller.
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

What about if load percentage is expressed in weight or volume instead of units?  Wouldn't it be a not-so-hard-to-program compromise?

For single type of cargo convoys, it would behave like now.  For multiple cargo convoys, it would be more balanced that it is now (not perfect though).


jamespetts

Quote from: isidoro on March 15, 2014, 12:58:17 AM
What about if load percentage is expressed in weight or volume instead of units?  Wouldn't it be a not-so-hard-to-program compromise?

For single type of cargo convoys, it would behave like now.  For multiple cargo convoys, it would be more balanced that it is now (not perfect though).



Hmm - I think that that would be very difficult for users to understand easily.
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.

ӔO

If the game could quickly show what % of pax/mail/goods the convoy can carry, that might make it easier, although it will add clutter.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

isidoro

Alternatively, Min. load can show tonnes instead of percentages: e.g. Min. load. [    ]/50 tonnes.  And the input (the brackets in the example) be a number from 0 to the max weight of the convoy cargo.

This system seems more natural and will scale well if Max. load. is implemented.  It could be used to limit the weight of a convoy that must pass a bridge in the route.

But there is a serious difficulty of this system that I can foresee: for the same category (bulk or goods, for instance), the weight of one unit of cargo will be different.  There is also a volume limit (not only weight) in vehicles: a truck cannot carry the same weight of uncompressed feathers than that of iron.

Ves

To address the issue with how much a ton is, there are two ways:

Add a new parameter in the vehicle .dat-file specifying "load maximum m3", (or load maximum m2 for instance for peace goods) and use m3 (or m2) as one of the loading factors, either visible or invisible to the player, or

A general setting in the simuconf.cfg, where the density of all kinds of goods are written and some mechanism to guess how much a car would load.

Vladki

IIRC boxed goods vehicles specify capacity in boxes (i.e. volume) and goods specify the weight of each box.