Recent Posts

Pages: [1] 2 3 4 ... 10
Simutrans Extended Development / Re: passenger and mail classes
« Last post by jamespetts on Today at 07:40:57 PM »
Thank you very much for all your work on this, and apologies that I have not had a chance to look at this earlier. I have now merged and pushed your latest work onto the passenger-and-mail classes branch after merging from the master branch and fixing the bug to which you refer above.

I am in the process of reviewing this, so I may amend this post in due course, but one thing that I notice is that the passenger display always separates passengers by class. It seems to me that this really ought to be optional, as there are many situations when it is more useful to know the total number of passengers than the details of the class; a simple checkbox, perhaps, which, when unticked, reverts to the old behaviour of treating passengers from all classes alike.
I think that I have now managed to fix this on the passenger-and-mail-classes branch. I have not yet incorporated your latest GUI code, as I wanted to leave that until after fixing this, but this now appears to work.

Would you be able to re-test to confirm? I should be most grateful.
Scenarios and Challenges / Re: Pak128 Scenario Tutorial
« Last post by gauthier on Today at 09:46:18 AM »
In addition of the comments I already made:

In the first steps (click on Isaac and on the town hall) when I click where expected, an empty message window appears.

2.H: problems with English translation: "Paso H", and "Public Stoppages" instead of "public stops".

3.G: Stars invasion again at the end of the step.

3.H.1: The piece of tracks on the slope where the player is supposed to start a tunnel is actually the result of a glitch/bug/unexpected-feature and might be confusing for beginners. As this piece is not necessary to start the tunnel and have it immediately connected to the tracks in front of it, it could be removed.

3.H.2: Since the player is instructed to set the layer level to 0, a note to tell him that this level is displayed in the toolbar, on the sliced underground mode button, would be great.

3.H.2: I think I already reported this one: "lower the terrain at the end of the tunnel" stays unclear to the player about what tool he should do this with (landscaping toolbar, lower flat slope tool).

3.I.5: Even if there is a note on how to set a signal's direction, player has no clue on how he has to set it to be OK. You could add a note telling that here the signals are in the good direction if there is only one signal outside the pair of tracks at each location.

3.I.5: Typos in the labels "Place Singnal here !."

3.J: The way you set train service here is quite ... unusual. Rio des Abajo is always served in only one direction by trains passing through it, and why having four different schedules when there is an obvious solution of having one line serving Cantebury - Rio de abajo - Westminster and backwards, and another line serving Cantebury and Lancaster ?

4.A: "oil" would be just enough instead of "hydrocarbons (petroleum)".

4.B: Please precise that docks have to be for goods (not passengers or mail).

4.E.1: The labels say "Build Track here!" instead of "Build canal here!".

4.E.2: There should be a not precising that canal need specific canal stops and not docks like on shores.

4.E.4: "You need 5 ships are needed" ;)

4.F: "Paso F" in English. No text is displayed in the scenario goal, I had to guess what to do, look for labels on the map, ...

4.G: "Paso G" in English. Same as before, no text displayed. I figured out with the error messages that I should have five ships, that the line should instruct to wait for 100% load at max 1/1 of month at Centebury, but I was unable to figure out what ship to use. Finally, when trying to start a Gripsholm on that line, an error message told me that I had to use a tanker. -> stuck again.
Well, there are some fundamental differences between passengers/mail and other goods.

  • Passengers are (at least initially) generated in rather small amounts over large areas. Goods is generated in large quantities in small, isolated locations.
  • Kind of related to the former, but since passengers are generated in small quantities in built up areas, you typically need lots of small stops to collect and "deliver" them. (Unless you go wild with huge subway stations, or even elevated solutions.) Industries often have open spaces around them for building large stations with lots of capacity, possibly even excess capacity depending on the pak sets cost modelling.
  • If the goods station serving a factory overflows, some amount of goods can be retained in the factory. If a passenger station overflows, new passengers will simply never materialize and the number of sad faces rise.
  • Real-life passengers are somewhat more impulsive, random and clever than goods. They can take a detour just for the journey itself. Real-life goods can also take apparently strange detours. Shipping raw materials from Europe to China in order for it to be manufactured into something that is shipped back to Europe makes some kind of whacked-up economic sense, but shipping raw material from Europe to China only to be shipped back unprocessed to Europe along with more raw materials to be processed in Europe makes no sense at all. (Of course, commuters do not tend to willingly take strange detours, although they sometimes have to due to cancellations and road construction work.)
  • Real-life passengers mostly route themselves (although there are deliberately connecting lines, where you might only have to buy one ticket). Real-life goods is routed by the shipping agent, which may deny some routes. (Some buses around here do not pick up passengers on part of their route, only drop off. Also vice versa, but that is slightly harder to control, except that passengers attempting it has to pay for a longer distance and hope that someone, preferably with a baby transport, stops the bus to get on where they want to get off. This has to do with higher-level politics, than pure logistics, though.)

One-way lines have been denied before. To change that, one probably should refute the argumentas against inclusion (which I do not remember). I don't think this was a matter of no available developers for it, which has been the case for lots of other wanted features.

In a sense, having only one-way lines in Simutrans may be too simplistic. Industries themselves only want to trade with certain other industries. Why shouldn't the players be able to choose to only work for certain industries, or even pairs of industries, rather than anything within the catchment areas? Overwhelming complexity perhaps.
Pak128.German / Re: Screenshots of PAK128.german
« Last post by pumuckl999 on Yesterday at 11:08:42 PM »
New loco-depot with water tower and a new freight-wagon left the depot.

No, the older animated "house with legs" in the background will never appear in our pakset :).

Simutrans Extended Development / Re: Loading addons crashes the game
« Last post by jamespetts on Yesterday at 10:16:16 PM »
Thank you for that. Are you able to upload a compiled pakset with a single override in which this problem can reliably be reproduced?
Scenarios and Challenges / Pak128 Northeast Corridor
« Last post by xiaopeng on Yesterday at 08:18:34 PM »
Having played Simutrans for a few years now, and seeing some of the impressive maps that people create (like the San Francisco map back in 2013), I decided to try my hand at creating a large map that could keep me occupied for a long time.  I made it on a Mac, so I hope it still works for those of you on Windows.

Map: The map I'm uploading here is 2200 x 2548 (much of that is the Atlantic Ocean, though), and covers as far south as Greenville, North Carolina, as far west as Pittsburgh, PA, as far north as Plattsburgh, NY, and as far east as Bath, Maine.  I think I got the map from the Simutrans Maps site, but I don't recall, and I did soften and blur the ppm with Gimp and carved out rivers as well, so it's been pretty heavily modified.

Cities: There are 1,888 cities placed as accurately as I could figure out with Google Maps and  There are some erroneously placed cities because Simutrans relocated some townhalls when I was growing them and I didn't care enough to delete and re-grow.  Oh well--the're not too far off.  As far as population, city-data had a nice set of maps with cities over 6,000 people, so I placed cities with at least 6,240 people so I could have 10% of real-world population.  I'm sure I have missed some places, but I did try to check with Google Maps by clicking on neighboring towns and placing them if they had enough people.  Total inhabitants of this map number 6,490,493, so you'll probably need a pretty powerful computer to play.  Maybe someday, I'll go through and redo the map with 1% of real-world population to make it a bit more playable.  I don't have enough time (or care enough) to manually place buildings and such, so I just used the "grow city" function, and tried to err on the side of having slightly too many people in a given town instead of slightly too few.  That way, if I need to bulldoze some buildings on the outskirts of town for my railways, the population will still be somewhat realistic.

Players: I have identified eleven of the largest transit agencies serving the Northeast US and Canada and made them into players.  I have also assigned one player for the airlines, renamed the public player "Government," and renamed the original human player "Unifying Transit."  There is one open slot in case someone wanted to add goods (do goods require a goods AI?) or an agency I missed.  At the moment, there are no industries on the map, although you can probably find a few squares of discolored earth where I deleted the industries that spawned while I grew the cities (I'm sure I missed some patches when I tried to re-color them the proper color).

Objective: My goal for this map is to first place, as accurately as possible, existing transit systems (perhaps optimized a little bit to include features that are in the planning or construction stages, like the Purple line in Maryland or a connection between the Red and Blue lines in Boston), then to go to town creating supplemental lines under the "Unifying Transit" player.  I hope to simulate Amtrak's major intercity services and perhaps some historic lines that no longer carry passengers.  Basically, the idea is to explore what transit could have been like if the interstates had never been built (I haven't placed many roads on this map, usually just bridges over rivers and stuff).  To assist with air travel, I have placed on the map airports with regularly scheduled passenger service to other cities on this map (so a few are missing because they lack service to another airport on the map), and plan on using the "Airlines" player to create somewhat accurate air routes ("somewhat" accurate because there will probably be A380's flying every route for purposes of capacity).

By happy circumstance, just over 41 years of game time elapsed while I was placing and populating the cities, so the game starts in May of 1971 (right when Amtrak took over).  The timeline is off (that's just how I like to play), as is city growth (can you imagine how bad it would get if it were on?).  Free-play is on because by the time I'm done building the infrastructure, I would be bankrupt with free-play off.  Although I created the map without using addons so I could share it, I plan to use LOTS of addons to play with it, mostly so I can have enough capacity with airplanes and the Acela Express/Northeast Regional trains so things won't completely grind to a halt.  I've got more than 3,700 addons in my Pak128 folder, so it should be fun!

Naturally, the file is too big to upload here, but I have placed it on Dropbox if anyone wants to download it and enjoy:
One must design networks to accommodate this behaviour. This usually means either going point to point (no interchanges) or going to dedicated interchanges (designed to cope with traffic in any direction, can alter schedule easily if a build-up occurs).

With passengers and mail I usually feed to a local interchange and then have that interchange transport to different local interchanges or a public interchange. This is not realistic but makes managing lines for no overcrowding and 100% pickup a lot easier. This same logic can be applied to goods as well although most of the profit will only be made between the interchanges due to double haulage. Might have problems with payment models that are not between stops due to some minor back haulage at points.
This is a recurrent problem in freight, I have the same issue with oil and refineries in an even more complex layout and I ended up building a big oil hub  :-[

If I had an extension request to make about these issues, it would be adding an option in schedules to force convoys to stay empty after one or several station, that could be used for trucks coming back from C to E and problem fixed.

Looking at your map, in my opinion, the best thing to do is to create a wood hub station in the middle with two lines of trucks: D-H-C and E-H-F (or D-H-F and E-H-C, or even something more complexe, depending on how balanced are production rates and consuming rates of your factories).

If your road network does not easily support this option, you can still go for E-D-C and D-E-F or for Leartin's solution (D-C, E-F and D-E).
Personally I don't really think that passenger generation is too low even with the current balance. However, it's easy to oversize the network and at times - just as in real life - one has to accept that providing passenger service to a little village or small town will be a money-losing project, just like a local bus line in a small town will run at a loss in reality. Thus it's either not connecting the small place or to accept the loss from connecting it.

The population density of a lot of buildings is too low currently and is in the process of being increased - but you are correct that smaller towns will not have a need for a dense transport network even after the changes.

A particular "trap" is that the most important metric to get passengers on your network is the frequency of the service - in Simutrans Extended frequency beats everything, speed and comfort don't really matter that much unless you have really large maps with long distance travel. Generally - and certainly with smaller towns - it's much better to run frequent but slow service with small buses than to have a fast but infrequent train service. Reason for this is that the sum of waiting time and travel time counts for passenger creation - and that sum can be lower with frequent slow service than for infrequent fast service.

And exactly this has been found to be the case in real life, at least for short distance transport where waiting time is a high proportion of the total journey time: see here for a history of the Exeter minibuses, a paradigm demonstration of this concept.
Pages: [1] 2 3 4 ... 10