News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Canal Overhaul

Started by TygerFish, December 07, 2012, 03:28:45 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

TygerFish

I'm experimenting with some changes to water vehicles and some of the reading I was doing (e.g. http://en.wikipedia.org/wiki/Narrowboat) gave me the idea to create more than just one canal way type.


I'm thinking at least two tiers for sure:


1) early/narrow[1500]: 25t (just Norfolk Wherry and horse barge)... or possibly 30t (+ diesel barge) or 32t (+steam barge)
2) existing[1750]: 80t (all small_waterway vehicles except Thames Sailing Barge fully loaded with most goods)


And maybe some others as well:


3) industrial revolution[1869 - Suez]: 1000t (steam passenger ships except the SS Great Eastern)
4) early modern [1914 - Panama]: 1200t (accomodates the new Clanline Steamer)
5) late modern [1960+]: 2500t (Handysize full of cars)


If any of those later ones are added, it would probably be a good idea to grant the canal way_constraint to ALL ships except larger wind-powered ones (Brig, East Indiaman, Blackwall Frigage, Schooner, and Clipper). This could actually be realistic, since I've read that the introduction of the Suez Canal did hasten the demise of clipper ships for trade.  It would make for an interesting in-game choice about whether to build an artificial canal on top of a river to allow heavier ships but disallow sailing ships.  Weight is not a perfect proxy for width, though it suffices.


A Suez-equivalent could in turn require creation of a new late-19th century sea freight vessel.  And any of the modern canals might also require some tweaking to the weight limits on the largest two river way types.


Any thoughts or input would be welcome.


Banksie_82

Here are my thoughts,

The Suez Canal is in fact a sea level crossing, not a canal that you would commonly see crisscrossing Europe. This is already able to be modelled in Simutrans quite effectively. Indeed, it was done so in the online game... although straight through the middle of an existing city is a little bit unrealistic. However, the Suez Canal is more like a single line railway, with a couple of passing loops along the way.  It was built this way to save costs and time... as you would expect.

The Panama Canal was also intended to be a sea level crossing. The French dug for years trying to create a sea level passage but due to geology and climate (lots of rain washing lots of dirt into their excavation) eventually gave up and walked away.

When the Americans took over the works they still intended for it to be at sea level. After suffering the same problems as the French, they decided to build a dam to create a lake (Gatuan Lake) and building the world's biggest locks to lift ships up to it. To this day, these locks dictate the maximum size a ship can be built to if it wants to use the Panama Canal, Panamax (although new locks currently being constructed will allow for "New Panamax" in 2014).

The Panama Canal is still considered to be one of the biggest engineering feats ever undertaken anywhere on earth. If we were to try to simulate this in Simutrans, I think the cost would need to be astronomical to avoid them going up to every bakery, saw mill and builders yard.

Personally, what I would like to see is, firstly, ships acting like other vehicles and not have an infinite amount stacked on top of each other. But also, for the smaller ships to behave like trucks/busses and take half a tile each and able to freely pass each other, while larger ships act like trains and take an entire tile and cannot pass on that tile.

While the former I believe is in the pipeline I think the latter may be just a little bit too hard.

TygerFish

Thanks for those thoughts and the history.  I agree with what you say about sea-level crossings... that's part of why I set the modern canals apart as an ambivalent maybe.  If the game had some way of making above-ground lakes, it would be a lot more realistic, but in the absence of that, forcing you to completely cut through the terrain does seem like an adequate simulation.

Any input on adding the smaller canal size?  I do still think it would be cool to differentiate larger and smaller canals.


Quote from: Banksie_82 on December 07, 2012, 04:31:50 AM
Here are my thoughts,

The Suez Canal is in fact a sea level crossing, not a canal that you would commonly see crisscrossing Europe. This is already able to be modelled in Simutrans quite effectively. Indeed, it was done so in the online game... although straight through the middle of an existing city is a little bit unrealistic. However, the Suez Canal is more like a single line railway, with a couple of passing loops along the way.  It was built this way to save costs and time... as you would expect.

The Panama Canal was also intended to be a sea level crossing. The French dug for years trying to create a sea level passage but due to geology and climate (lots of rain washing lots of dirt into their excavation) eventually gave up and walked away.

When the Americans took over the works they still intended for it to be at sea level. After suffering the same problems as the French, they decided to build a dam to create a lake (Gatuan Lake) and building the world's biggest locks to lift ships up to it. To this day, these locks dictate the maximum size a ship can be built to if it wants to use the Panama Canal, Panamax (although new locks currently being constructed will allow for "New Panamax" in 2014).

The Panama Canal is still considered to be one of the biggest engineering feats ever undertaken anywhere on earth. If we were to try to simulate this in Simutrans, I think the cost would need to be astronomical to avoid them going up to every bakery, saw mill and builders yard.

Personally, what I would like to see is, firstly, ships acting like other vehicles and not have an infinite amount stacked on top of each other. But also, for the smaller ships to behave like trucks/busses and take half a tile each and able to freely pass each other, while larger ships act like trains and take an entire tile and cannot pass on that tile.

While the former I believe is in the pipeline I think the latter may be just a little bit too hard.


kierongreen

Above ground lakes are coming when new landscape patch gets added to trunk.

jamespetts

Adding multiple canal types has been in the pipeline for some time, and I was planning to work on it over Christmas: see here. Indeed, I have an entire book on the history of canals for this very purpose. Perhaps we could work on this together?
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.

TygerFish

I'd love to collaborate!  My thinking thus far has focused more on the 19th century and on ships more generally, but it's definitely related subject matter.

My current local build also has explicit loading times for all water vehicles, although it's based only on game-balancing intuition with very little input from real-life data.  I have been pleased with some of the emergent phenomena around larger ships taking longer to load; if you haven't put any of those into yours yet, I'll post what I've got so far.

Quote from: jamespetts on December 07, 2012, 09:39:49 AM
Adding multiple canal types has been in the pipeline for some time, and I was planning to work on it over Christmas: see here. Indeed, I have an entire book on the history of canals for this very purpose. Perhaps we could work on this together?

greenling

All
It very nice that a work around for canal now beginn.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

Very interesting. I do have loading times encoded for all the ships, but they are not based on any real life data, as such data are very hard to come by. What are the results from your work on having larger ships have longer loading times?

As to producing canal and barge graphics, may I ask: have you had any experience at producing graphics for Pak128.Britain before?
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.

TygerFish

Quote from: jamespetts on December 08, 2012, 10:38:38 PM
Very interesting. I do have loading times encoded for all the ships, but they are not based on any real life data, as such data are very hard to come by. What are the results from your work on having larger ships have longer loading times?
The interesting and realistic emergent property is that it's no longer efficient to use large ships for short trips or on routes with a lot of stops.  This provides a reason to use smaller ships (or even to build canals/roads/rails!) on local coastal routes and keep the larger ships as the long-haul vehicles they're supposed to be.

Where did you put your loading time changes?  I don't see any on github, for instance here: https://github.com/jamespetts/simutrans-pak128.britain/blob/master/boats/schooner.dat

Quote from: jamespetts on December 08, 2012, 10:38:38 PM
As to producing canal and barge graphics, may I ask: have you had any experience at producing graphics for Pak128.Britain before?
I've played around with some graphics files in my recent experiments, but it's just been very basic stuff: changing the palate or making simple changes to existing graphics.  Alas, my graphics skills are quite primitive, so I will be of limited help in that area.

greenling

Tygerfish
I this link how you be post have gives no loadingtime entry.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

Hmm - you are correct, it seems: I have not, in fact, added loading times to a number of the ships. My error. If that is so, then I should be very interested in adapting your loading times - are you able to set up a Github branch so that I can merge easily/automatically (indeed, have you done so already)?

As to the graphics, see here for information on how to make graphics for the pakset. In summary, you need to use Blender, a free and open-source 3d modelling application: you don't need to be any good at pixel art, since it's just a matter of rendering. The easiest way to get started is to make small modifications to existing vehicles/buildings. If you were to work on the project and produce graphics, you might be interested in producing the vehicle graphics (various types of canal barges), since they would all be quite similar to each other (and similar to the existing barges) and would be fairly easy to get started with producing. It would be very helpful to have assistance with graphics, since this is one of the more time consuming areas.

If you found that the graphical side of things are too difficult, you can still be of some assistance, for example, in producing .dat files.

Let me know what direction that you'd like to take so that we can collaborate more effectively. Thank you for your offer of assistance - it is much appreciated.
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.

TygerFish


Quote from: jamespetts on December 09, 2012, 07:00:56 PM
Hmm - you are correct, it seems: I have not, in fact, added loading times to a number of the ships. My error. If that is so, then I should be very interested in adapting your loading times - are you able to set up a Github branch so that I can merge easily/automatically (indeed, have you done so already)?
Okay... this is a lot. :)

I've been experimenting with a number of other changes as well in parallel, but I've checked the boat changes into a new branch... keep in mind that this is not finished yet:
https://github.com/calvin-fisher/simutrans-pak128.britain/tree/testing

While experimenting with the loading times (and other things), I've been using a spreadsheet to keep track and get an overview:
https://dl.dropbox.com/u/7182124/Simutrans%20Ship%20Balance.xlsx
Entirely new things are in orange, changed (or probably-to-be-changed) things are in yellow.

I made up some graphs of a very incomplete subset of the existing loading times, just to get a general idea of what the existing balance was:
https://dl.dropbox.com/u/7182124/passenger_loading_efficiency.png
https://dl.dropbox.com/u/7182124/passenger_minimum_loading_time.png
https://dl.dropbox.com/u/7182124/road_vehicles_loading_efficiency.png
https://dl.dropbox.com/u/7182124/road_vehicles_minimum_loading_time.png

In many cases, the trend lines are rather arbitrary, because intro_year does not take into account a lot of things (like the size of vehicle, for instance).  But in general, it looked to me like the existing rules had the following trends:
* Mail loads about half as fast as passengers
* Freight loads several times slower than mail
* Road vehicles load about half as fast as rail vehicles
* Water vehicles have a significantly longer minimum loading time than road vehicles, especially the larger/seagoing-only ones
* In terms of loading time per unit of cargo, larger water vehicles are excellent -- about on par with road vehicles
* All things being equal, loading time decreases over time

Based on that, I decided the following:
* The difference between cargo type would be lessened in water vehicles because all loading times are longer
* Larger ships definitely should have longer minimum loading times than smaller ships (because they have to take on crew, load extra provisions, etc.)
* Smaller ships -- especially canal-going ones -- should have minimum loading times long enough that anything is better for very short trips, but still short enough that they are a good option for midrange trips before mid-19th century

There definitely needs to be some more tweaking to all of those numbers, though.  The multi-segment ships (e.g., East Indiaman) in particular need some more work, I think.

That branch and the spreadsheet also reflect a bunch of other experimental changes... full notes here:
https://dl.dropbox.com/u/7182124/water_changes.doc

As I mentioned before, there are some interesting emergent properties that I'm seeing with the version built from that source:
* Water vehicles -- especially larger, seagoing-only ones -- are suited to transporting goods over long distances, where loading them on/off the ship isn't as much of an issue; for shorter trips along the coast, it will make more sense to use another mode of transportation.
* It can actually make sense now to build a canal near a coastline (or a rail line; those early rail lines were always notoriously useless, IMO)
* Non-time-sensitive cargo (bulk, long) cares less about slow trips, and will continue to use ships (especially the larger ones) after other forms of cargo have moved onto faster modes of transportation


Quote from: jamespetts on December 09, 2012, 07:00:56 PM
As to the graphics, see here for information on how to make graphics for the pakset. In summary, you need to use Blender, a free and open-source 3d modelling application: you don't need to be any good at pixel art, since it's just a matter of rendering. The easiest way to get started is to make small modifications to existing vehicles/buildings. If you were to work on the project and produce graphics, you might be interested in producing the vehicle graphics (various types of canal barges), since they would all be quite similar to each other (and similar to the existing barges) and would be fairly easy to get started with producing. It would be very helpful to have assistance with graphics, since this is one of the more time consuming areas.

If you found that the graphical side of things are too difficult, you can still be of some assistance, for example, in producing .dat files.

Let me know what direction that you'd like to take so that we can collaborate more effectively. Thank you for your offer of assistance - it is much appreciated.
I'll take a look at blender at some point.  Graphics really are not my strong suit, but I'm certainly happy to try.  As for the dat/balance angle... well, see above. :)

greenling

Tygerfish
I will look in your data on the weekend.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

Thank you for your extensive work on this - it is much appreciated. A few queries, if I may. Firstly, did you intend to reduce the running costs of mail carrying paddle ships to zero? Secondly, about the small waterway constraint: this allows the ships to use really quite small rivers and canals. "Wide rivers" can already be used by sea going vessels. Is this not sufficient? I do plan to have a greater range of constraints for canals soon for various types of canal/river; perhaps this would cover it? I don't think that ocean going paddle steamers and brigs should be allowed on "small river" types, which are equivalent to the upstream parts of, e.g., the Thames at Maidenhead:



This sort of paddle steamer is probably the largest that can fit on the river at this point (see the bridge in the background), and this would certainly not be usable for sea voyages.

Thirdly, if you are removing things, you need to be careful not to break compatibility with saved games from older versions: you need to add lines in compat.tab substituting the removed things for other things still in the pakset. You need to do this every time that you change the base (not translated) name of any object, too.

Fourthly, I am not convinced about the overcrowded capacity use on boats: if the idea is to get lower comfort, it is better just to adjust the comfort rating directly. Boats do not, to my understanding, tend to run actually overcrowded - do you think that they did in the past? I should be interested in the nature of any research on the subject.

Those issues aside, however, this (especially the addition of loading times) is very worthwhile work for which I am extremely grateful. Once the issues above are addressed, I should very much like to merge this with my Github branch to go in the next version: this will save me a considerable amount of work.

We can then start to make some progress with canals. As to graphics, if you are not confident making graphics in Blender, you might be able to save me some time by processing the graphics (this is a semi-automated process that uses special Windows software written by a Simutrans devotee in addition to the Gimp (or Photoshop if you prefer) and making .dat files based on specifications that we discuss here. That could be a viable workflow, especially since, over Christmas, I shall be staying somewhere with access only to Linux computers, and therefore unable to process the graphics.
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.

sdog

overladen boats must have been common place, with many accidents caused by this. I would be surprised if it was any different in the UK. Here are two examples:

99 – Meikle Ferry disaster, Dornoch Firth, Scotland; over-laden ferryboat sank with the loss of 99 lives (16 August 1809).
http://www.historylinksarchive.org.uk/picture/number4830.asp

60+ – Harwich ferry disaster, a 'grossly overladen' coastal vessel capsized whilst transporting soldiers and their families, (18 April 1807)
http://en.wikipedia.org/wiki/Harwich_ferry_disaster


jamespetts

Interesting research! Perhaps, then, we should allow overcrowding of older boats, but prohibit it on newer boats built in times of greater awareness of safety?
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.

wlindley

The original Railroad Tycoon let you operate your trains faster than 100% but at increased risk of a crash (and loss of the train and cargo).

Unless we are simulating safety-factors, we ought not to let early boats and ships be too overcrowded.

Although, if we did, I have this idea for a company in the online game, maybe I'll call it "Lloyd's of London" ...

jamespetts

Yes, indeed: it's a matter of balance, I think. Some overcrowding of early boats might be desirable in the light of Sdog's research.

As to Lloyd's - you may laugh, but have you ever played "The Business Game", otherwise known as "Mine a Million"? I play that sometimes with my family, and have modified it so as to introduce maritime insurance...
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.

sdog

Perhaps a rule of thumb would be to overcrowd only very small vessels, like ferry boats and river steamers. The cheaper the passage the more likely the overcrowding. It seems to have been common practice with very rare (but horrible) accidents. Modeling a higher risk of accidents with overcrowding is likely not required.

ps.: were small ferry boats registered with maritime insurers at all?

TygerFish

I could see the rationale for doing overcrowding only/primarily on early/smaller ships being that only ships intended for shorter voyages would accommodate overcrowding.  The smaller paddle steamers, for example, might well have people on deck without cabins.

My original thinking behind trying out overcrowding was to try modeling the 1st/2nd/etc class structure, but doing this just with overcrowding seems to have some unintended side effects, especially when the overcrowded capacity is significantly larger than the regular capacity. Another idea I will have to experiment with was to add another segment onto the ship convoy.  For example, change ShipNameAddPax to only 20 passengers with no overcrowding, and introduce a ShipNameAddPaxCoach (aside: what would be the historical term for lower class passage on a ship? Can't recall just now...) that follows it with 60 passengers, a lower base comfort, and up to 20 overcrowding.

Quote from: sdog on December 12, 2012, 03:43:20 PM
Perhaps a rule of thumb would be to overcrowd only very small vessels, like ferry boats and river steamers. The cheaper the passage the more likely the overcrowding. It seems to have been common practice with very rare (but horrible) accidents. Modeling a higher risk of accidents with overcrowding is likely not required.

ps.: were small ferry boats registered with maritime insurers at all?

greenling

Jamespetts
the ship on the photo looks very nice out.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

AP

Quote from: TygerFish on December 12, 2012, 04:03:38 PMaside: what would be the historical term for lower class passage on a ship? Can't recall just now...
steerage passengers?

TygerFish

Yes, exactly!

I'll play around with breaking out AddPax and AddPaxSteerage.  Does anyone have any suggestions on the relative comfort levels?  Half?  A third?

Quote from: AP on December 12, 2012, 08:00:19 PM
steerage passengers?

AP

The link I posted had images of the White Star line accomodation from the c19th. Looks very cramped indeed.

The Hood

Quote from: TygerFish on December 12, 2012, 08:08:37 PM
Yes, exactly!

I'll play around with breaking out AddPax and AddPaxSteerage.  Does anyone have any suggestions on the relative comfort levels?  Half?  A third?


Just a word of warning - I'm planning on recoding ships so the hull is a "locomotive", i.e. no cargo, and then you can fit it out with various cargo holds (like carriages). Not sure if this will then make its way into experimental though.

TygerFish

Do you mean you're planning to just have a set of rigid cargo loadouts as now, but to make the decision about which loadout to have based on a second click rather than searching through the list of vehicles?  Or did you mean to make finely-customizable loadouts possible?  The finely-customizable interpretation sounds a bit unwieldy.  But I like the former idea a lot, actually.  Assuming that's what you mean, when are you planning on doing it, and have you decided on a naming scheme for the new system?

As long as James doesn't have any objections, I would be happy to include that change in parallel in my present work if the timeframes are compatible; either set of changes would involve needing to re-provision ships in any existing saved games, might as well do it all at once.

(also James -- full reply to your earlier post coming later!)

Quote from: The Hood on December 12, 2012, 08:51:39 PM
Just a word of warning - I'm planning on recoding ships so the hull is a "locomotive", i.e. no cargo, and then you can fit it out with various cargo holds (like carriages). Not sure if this will then make its way into experimental though.

jamespetts

TygerFish,

I don't have any objections to you including this proposed change in parallel for your present work, as long as the two are broadly compatible (especially as far as loading games saved in Standard in Experimental is concerned).

One other thing: while you are doing this work, would you be able to add The Hood's latest boats (all those ships from the latter part of this year that have not made it into my Github repository yet) to your branch, and add comfort and loading times to them compatible with your existing system? That would save me a great deal of work.
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.

TygerFish

Quote from: jamespetts on December 12, 2012, 01:17:28 AM
Firstly, did you intend to reduce the running costs of mail carrying paddle ships to zero?

Yes, for the time being -- the maintenance costs were so high on those that I was having trouble getting many of the steam ships to run at a profit.  I figured it would also be easier to tweak the maintenance cost for the ship if it was all in one place rather than spread out among its parts... unless the part is optional and incurs an additional cost beyond the base minimum.


Quote from: jamespetts on December 12, 2012, 01:17:28 AM
Secondly, about the small waterway constraint: this allows the ships to use really quite small rivers and canals. "Wide rivers" can already be used by sea going vessels. Is this not sufficient? I do plan to have a greater range of constraints for canals soon for various types of canal/river; perhaps this would cover it?

If we take that segment of the Thames near Maidenhead to be a Small River (<75m wide; only truly small ships fit) and the downriver segments to be Wide River (upwards of 1km wide; problematic for game scale, but accomodating basically anything), what do you have in mind for the River waytype?  My intuition is that the medium River -- which currently requires small_waterway -- should accommodate almost all of the paddle steamers; even the monstrous SS Great Eastern was launched from Millwall, where the Thames is about 250m wide -- barely more than the ship's length.

For the time being, I was using the weight limits as an additional filtering mechanism.  It's not a perfect abstraction, but it might still be useful in some cases.  The additional way constraint you have planned will probably help refine these distinctions a lot.

I think some additional moderately-sized steam ship types are probably warranted as well.  I'll take a look at what TheHood has already.


Quote from: jamespetts on December 12, 2012, 01:17:28 AM
Thirdly, if you are removing things, you need to be careful not to break compatibility with saved games from older versions: you need to add lines in compat.tab substituting the removed things for other things still in the pakset. You need to do this every time that you change the base (not translated) name of any object, too.

I was not aware of this! Thank you for pointing it out.

Quote from: jamespetts on December 12, 2012, 01:17:28 AM
Fourthly, I am not convinced about the overcrowded capacity use on boats: if the idea is to get lower comfort, it is better just to adjust the comfort rating directly. Boats do not, to my understanding, tend to run actually overcrowded - do you think that they did in the past? I should be interested in the nature of any research on the subject.

I'm not entirely convinced myself... see above discussions.  The AddPax vs AddPaxSteerage distinction seems promising, though, and we can thereby limit the overcrowding only to the steerage section.


Quote from: jamespetts on December 12, 2012, 01:17:28 AM
Once the issues above are addressed, I should very much like to merge this with my Github branch to go in the next version: this will save me a considerable amount of work.

I wouldn't want to incorporate prematurely though!  :)  There's a reason I shunted this off to a testing branch in my own repository; I still consider all these changes purely experimental (no pun intended) and wholly subject to rejection.  I'd welcome anyone else's feedback as pertains to improving anything.


Quote from: jamespetts on December 12, 2012, 01:17:28 AM
you might be able to save me some time by processing the graphics (this is a semi-automated process that uses special Windows software written by a Simutrans devotee in addition to the Gimp (or Photoshop if you prefer) and making .dat files based on specifications that we discuss here.

I would be happy and able to help in that capacity!

TygerFish

I'll coordinate with The Hood to incorporate as much as possible.  And I will keep this guideline in mind: "make sure games saved in standard can be loaded in experimental."

Quote from: jamespetts on December 12, 2012, 11:33:47 PM
TygerFish,

I don't have any objections to you including this proposed change in parallel for your present work, as long as the two are broadly compatible (especially as far as loading games saved in Standard in Experimental is concerned).

One other thing: while you are doing this work, would you be able to add The Hood's latest boats (all those ships from the latter part of this year that have not made it into my Github repository yet) to your branch, and add comfort and loading times to them compatible with your existing system? That would save me a great deal of work.

jamespetts

On the running costs, the error was mine, I think: I had not realised that "IronPaddleSteamerMail" (etc.) was the mail addon for the iron paddle steamer, not a ship in its own right. It does make sense for the addons to be free, so your original decision was correct.

On the question of constraints, we need to think carefully of a new set of constraints, I think. The existing "waterway" constraint needs to be retained in its current form (as a permissive constraint for flat bottomed river vessels such as canal barges and the like), but "small waterway" needs to be replaced with a series of more precise prohibitive constraints. There are a total of 8 possible prohibitive constraints. "Tube tunnel" is currently one of them, "tramway" another,  and "small waterway" is the third, so, taking into account the fact that we are re-cycling "small waterway", we have up to six prohibitive constraints to use for different sizes of waterways. We don't need to use all six, of course, but 3-4 might well be of utility. I am thinking about being fairly precise about these constraints, using historical canal sizes as a start (7ft, 14ft, etc.), but I should be interested in any views that you might have on the subject.

As to overcrowding, we should use the overcrowding figure to represent actual overcrowding, e.g., boats taking on more passengers than they have cabins, which passengers then have to stand on the decks. This might work for 19th century small ferries, but not, I think, for larger, ocean-going ships. I am not sure that having separate "AddPax" and "AddSteerage" modules is the way to go, because all boats that were equipped for passengers, I think, would have been equipped for a mixture of different sorts of passenger accommodation, including steerage and better sorts of births, so a single "AddPax" (translated as "passenger deck") is probably sufficient for the modular system proposed by The Hood.

Thank you very much indeed for all your help on this - it is very much appreciated. I shall let you know when I start producing canal related graphics and explain how to process them.
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.

greenling

Jamespetts,Tygerfish,The Hood
Thank you that are make a work around from the Canals be make.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

TygerFish

Quote from: jamespetts on December 13, 2012, 12:16:20 PM
On the question of constraints, we need to think carefully of a new set of constraints, I think. The existing "waterway" constraint needs to be retained in its current form (as a permissive constraint for flat bottomed river vessels such as canal barges and the like), but "small waterway" needs to be replaced with a series of more precise prohibitive constraints. There are a total of 8 possible prohibitive constraints. "Tube tunnel" is currently one of them, "tramway" another,  and "small waterway" is the third, so, taking into account the fact that we are re-cycling "small waterway", we have up to six prohibitive constraints to use for different sizes of waterways. We don't need to use all six, of course, but 3-4 might well be of utility. I am thinking about being fairly precise about these constraints, using historical canal sizes as a start (7ft, 14ft, etc.), but I should be interested in any views that you might have on the subject.
I agree that something more fine-grained like this would probably give the most accurate results.  Really, the only reservation with that that comes to mind right now is to make sure we don't get *too* fine-grained, to the point where the pak doesn't have enough vehicle diversity to support it, or it gets unwieldy to manage.

In your research, are/were there standard or convergent/common/de facto standard canal sizes?  I think I would want to learn more about the actual history before weighing in.

Quote from: jamespetts on December 13, 2012, 12:16:20 PM
As to overcrowding, we should use the overcrowding figure to represent actual overcrowding, e.g., boats taking on more passengers than they have cabins, which passengers then have to stand on the decks. This might work for 19th century small ferries, but not, I think, for larger, ocean-going ships. I am not sure that having separate "AddPax" and "AddSteerage" modules is the way to go, because all boats that were equipped for passengers, I think, would have been equipped for a mixture of different sorts of passenger accommodation, including steerage and better sorts of births, so a single "AddPax" (translated as "passenger deck") is probably sufficient for the modular system proposed by The Hood.
Regarding the accuracy of overcrowding, I'm not absolutely certain of this, but I seem to remember that unlike our modern-day notions of fixed capacity, a pre-20th century accommodation might have been routinely shared by multiple people, and that this was especially common among the lower class accommodations.  Sort of like with residental accomodations -- today, we're surprised to hear of immigrant families cramming 8 or 12 people into an apartment rated for 2/3 occupants, but the practice was much more common in the past.  With ship cabins specifically, I think I even recall hearing about specific instances where overcrowding resulted in safety issues, but I can't recall for sure.  At any rate, I could definitely see the rationale for at least some small amount of overcrowding in water vehicles.

Also, a point of clarification -- would doing it the way I'm envisioning actually have the effect that I'm looking for?  For example, in a two-part vehicle with a fixed number of higher-comfort 1st class passengers and a larger number of lower-comfort steerage passengers with additional overcrowded capacity, I would expect that the comfort/fares for each vehicle in the convoy are calculated independently of one another, and that one overcrowded vehicle would just affect that vehicle, not the whole convoy.  Is that  correct, or would it be functionally the same as just averaging the two parts into one vehicle?  I haven't looked through the comfort/fare code to determine the exact behavior.

greenling

Tygerfish
That it a good qustion they you speak on.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

TygerFish

I added everything from SVN into my github repository last night that wasn't already in experimental.
https://github.com/calvin-fisher/simutrans-pak128.britain/commit/43efc6ecbf4f6dc719bc5adcb5b2e71e83d6f5b3
The next step is to add in balanced loading/comfort/cost/etc.

The only thing I didn't include yet was The Hood's reworking of the large ships into a hull-hold model.  I did move that over, but I'm going to keep that in a separate branch for now until we finish any additions/tuning/tweaking.

Quote from: jamespetts on December 12, 2012, 11:33:47 PM
TygerFish,
One other thing: while you are doing this work, would you be able to add The Hood's latest boats (all those ships from the latter part of this year that have not made it into my Github repository yet) to your branch, and add comfort and loading times to them compatible with your existing system? That would save me a great deal of work.

AP

Quote from: jamespetts on December 12, 2012, 12:11:56 PM
Interesting research! Perhaps, then, we should allow overcrowding of older boats, but prohibit it on newer boats built in times of greater awareness of safety?
Pretty sure that it was more to the experience of the captain concerned. I don't think overcrowded boats were standard practice, or the casualty rates would have been far higher/more frequent.