Topic: Portals

[jamespetts]

As discussed here, one of the planned features for Extended is portals: the ability so simulate long distance, intercontinental length routes for ships and aircraft without a map size to match.

However, one problem with this is how to deal with timing. A very simple way of dealing with timing would be for the vehicles to wait at the portal for the equivalent amount of time that their off-map journey would take, then load/unload, then wait again for their off-map journey time before appearing at the map edge portal having completed the journey within the time.

However, for long journeys by sea, this is problematic given the two time scales in the game, the short and the long time scale. Normally, this is not a difficulty: every month is (by default) 6.4 hours, and most journeys are completed well within that time. Even a journey taking one or two game months is not a significant problem.

However, for long voyages, this is unworkable. In the mid 19th century, for example, travelling from London to Australia could take up to four months. Assuming 30 days per month at 24 hours per day, this is 2,880 hours or 450 game months, being 37.5 game years; in other words, a voyage would start in, say, 1850, and the return trip would take until 1925 to complete (not counting loading time). By that time, many new generations of boats would have been invented, rendering the original voyage pointless.

A straightforward solution to this would be not to simulate the journey time, but instead have the vehicle load/unload as soon as it reached the portal, and turn around again after it has finished loading/unloading, but calculate what the running cost, fixed maintenance cost, vehicle wear (when this system is implemented) and revenue would have been for the longer journey and apply these automatically all at once at the portal (twice: once when arriving, and then again when leaving). This would have the result that the length of the journey is simulated in some respects economically, but is kept within the parameters of the journey time within which it is workable given the dual time scale.

However, there is a further problem with this, in that it fails to simulate the realistic capacity of any given vehicle on the route. Imagine the London to New York route, for instance: the Boeing 707 completed this in 6 hours. If it were possible for a player to complete this in, say, 1 in-game hour (but with running costs and revenue charged and paid as if it were conducted in 6), then each aircraft would be able to carry 6 times as many passengers on the route as if the full length of the journey were simulated. A possible solution to this, in turn, is to charge the player an amount representing the additional cost of purchasing/hiring additional vehicles to cover the route at the higher service frequency in question.

Calculating this, however, is tricky. Take the example of the Boeing 707. In 1957, this cost US$4.3m. A player with 1 Boeing 707 could, in our scenario, use that one aircraft to transport as many passengers as 6 Boeing 707s were the full journey time simulated. However, one cannot simply charge the cost of 5 Boeing 707s per trip, as the other (nominal) 5 would be used for more than one trip. Also, the player might actually only want to run with the equivalent capacity of one aircraft for the trip even if the time were accurately simulated because, for example, there might not be the demand to run more than one, and so insert a large waiting time at both ends of the trip to regulate the service. This waiting time could in principle be taken into account, but players might exploit this by changing the schedule manually to set off early: because there is no record currently kept as to whether this has happened, this exploit would not be easy to prevent.

The exploit aside, presumably what one really needs to do is to work out the cost of the depreciation of the asset in question during the extra time that would have been taken had the time been simulated fully. To calculate the depreciation, it would be necessary to know the vehicle's scrap value and its estimated lifetime. The latter should in principle be straightforward to ascertain (the idea of having a scrap value for other purposes, i.e. to be the only disposal value of a vehicle for which a second-hand buyer cannot be found when the system of second-hand sales is introduced, is already under consideration), but the estimated lifetime is very hard to calculate: a vehicle might be disposed of early because its route has become uneconomic and there are no other duties for it or because it has been made obsolete by rapidly advancing technology; on the other hand, a vehicle might last significantly longer than expected by reason of light use, its inherent durability and/or lack of better alternatives.

Since this feature is of some importance to allow for many types of ships and aircraft, as well as industry that relies on imports (and new goods types, such as tea, that are only imported), finding a resolution to these issues is of particular importance.

In particular, if anyone has an idea of how to address:

(1) the exploit;

(2) the depreciation calculation; or

(3) an alternative means of solving the basic problem,

then I should be most interested in such ideas.

[Yona-TYT]

I suppose the map generator might be able to create a list of industries / cities located on other continents. Then you can choose one of those industries or cities to import / export the load.

[Vladki]

Which timescale rules the speed of vehicles? If I have 8 tiles per km, 6:24 hours per month and vehicle running at 10 km per hour, will it make 80*6.4 tiles per game month?

[jamespetts]

I suppose the map generator might be able to create a list of industries / cities located on other continents. Then you can choose one of those industries or cities to import / export the load.

I am not quite sure how you envisage this working - I had envisaged special portal tiles at the map edge that demand passengers and mail and demand and produce goods, and which also act as portals in the way described above.

Which timescale rules the speed of vehicles? If I have 8 tiles per km, 6:24 hours per month and vehicle running at 10 km per hour, will it make 80*6.4 tiles per game month?

All calculations relating to the speed, revenue and maintenance cost of vehicles use the short time scale (i.e. 6.4 hours rather than one month).

[Jando]

... (3) an alternative means of solving the basic problem,

then I should be most interested in such ideas.

I believe the basic problem is that we have vehicles with a range far exceeding any reasonable map size. The obvious easy solution to this is to remove these vehicles from Simutrans Extended. Personally I would not even mind that solution, because a simulation can never correctly simulate all scales of reality anyway. Simutrans Extended is very good at simulating local and regional transport, even up to a national scale, but we can't expect that for intercontinental transport as well.

That said, it's obviously also well within the scope of Simutrans Extended to simulate the local and regional transport of exotic goods that might arrive via intercontinental transport. For that "portals" are a very fine idea, though I would probably rather call them intercontinental or long-range trade hubs or something like that.

If I would be asked to design a way of simulating the transport of exotic goods and intercontinental passengers on a local and regional map scale I would devise an airport and harbour extension that can be build by players. This extension would generate exotic goods, would demand manufactured goods and have  demand for passengers and mail as well as generating those. To make it not too easy for the player I would limit the number of extensions that players can build, say, to 1 airport and 1 port extension per 20 or 30 towns. That way Simutrans Extended could still have exotic goods and passengers, but would not need to simulate all the aspects of intercontinental long-range transport.

[jamespetts]

I believe the basic problem is that we have vehicles with a range far exceeding any reasonable map size. The obvious easy solution to this is to remove these vehicles from Simutrans Extended. Personally I would not even mind that solution, because a simulation can never correctly simulate all scales of reality anyway. Simutrans Extended is very good at simulating local and regional transport, even up to a national scale, but we can't expect that for intercontinental transport as well.

This is not really a solution to the basic problem so much as a means of giving up trying to find one. Simulating long distance air and sea transport is a very interesting thing in itself, and is very unclear precisely what the cut-off would be. Would one include cross-channel ferries (which are capable of crossing ssuch as Dover-Calais but also much longer trips such as Hook to Harwich or even Southampton to Northern Spain)? Medium-range aircraft such as the Airbus A300? Mixed-range aircraft such as the Boeing 737, Boeing 727, DC-6 or BAE 146 (the latter three of which are already in the pakset)?

There is then the difficulty of simulating airport economics realistically with airports only dealing with short-haul flights, as this greatly increases the maintenance cost per aircraft that must be paid.

[Jando]

This is not really a solution to the basic problem so much as a means of giving up trying to find one.

Oh, that is correct, I fully agree with you. The approach I have discussed does not solve the basic problem at all, it only avoids it.

Simulating long distance air and sea transport is a very interesting thing in itself, and is very unclear precisely what the cut-off would be. Would one include cross-channel ferries (which are capable of crossing ssuch as Dover-Calais but also much longer trips such as Hook to Harwich or even Southampton to Northern Spain)? Medium-range aircraft such as the Airbus A300? Mixed-range aircraft such as the Boeing 737, Boeing 727, DC-6 or BAE 146 (the latter three of which are already in the pakset)?

I tend to play on smaller maps thus I cannot even try to judge that. How big (in terms of square kms are about the largest maps people make? My feeling would say that distances like Dover-Calais, UK-Holland or UK-Ireland are well within the scope of Simutrans Extended.

There is then the difficulty of simulating airport economics realistically with airports only dealing with short-haul flights, as this greatly increases the maintenance cost per aircraft that must be paid.

I have little experience with trying to run planes on Simutrans (in the old Experimental I think). Only really tried it once with air transport to islands a short way (20 kms or so) off the coast to avoid the loading times on ships. Never could make any profit from it.

[Ves]

What about something like this:

When the game is initially created, a set of 'out of map'-cities are created as well. These cities have a fixed place in relation to the map and they will be persistent during the entire game and only the public player would be able to add more distant cities, remove them, alter them etc. the cities would have different good that they export and import, and will have contracts with factories on your map. There could potentially be hundreds of distant cities.
The distant city will also specify which ways of travel that you can reach the city (that would only be by air or water). Some randomness would decide if a city builds an airport, but it would always be of the highest standards so you don't need to worry about runway length or max weight.

The player will be able to see all cities as markers around the edge of the map, as well as which factories is connected.
I think it, for the sake of the immersion, it is very important that the vehicle them selfs don't land or dock at the edge, but they should sail/fly over the edge and vanish completely.

In regards of the timing, you could also have the middle way that is that they travel in true speed for a set amount of km and then there is an increased speed exponentially with the distance the vehicle has to travel outside the map.
Example: if the distant city is 10.000 km out from the edge of the map, then the plane or boat will go in realtime speed the first say 5.000 km and then it will accelerate and travel the rest of the distance faster. That would cut the top of the longest journeys but still keep the relative long distance for the nearer towns. Maybe only use that for boats, since airplanes making such trips anyway does it in reasonable time.

[Vladki]

I like Ves' suggestions, but: keeping the vehicle visible on the edge of the map, makes it easier to find it.

To the timescale, I would use the month scale for boats that are out of map. Perhaps not for planes. Also a minimum distance would have to be enforced (eg. 10x map size) so that the out of map cities are realy far away, and not just behind a corner.

Or even a wilder idea, only for network games: have the game servers cooperating. A plane or boat would be allowed to travel between the servers. Admins would be able to set the distance between the two maps, and vehicles would disappear from one server and after some time pop up on another...

[jamespetts]

There are a number of quite complex suggestions here, although none of them actually address the problem of calculating (or at least reasonably approximating) the extra profit to the player brought about as a result of the time taken to travel between the portal and the edge of the map is less than the time would be if it were done in a consistent scale. All of the various different suggestions about timings (along with other ideas that I had considered, such as having a maximum time outside the map and then stopping, and so forth) have the same problem in calculating and then compensating for this additional benefit. (I should note that the idea of an exponential increase makes this calculation orders of magnitude more difficult).

One idea of a means of dealing with this issue in a way transparent to the player (although this still does not resolve the calculation issue) is to charge players fixed landing/docking fees for foreign ports/airports rather than a percentage of the revenue as is charged for ports and airports on the map. However, it is not at all clear to me how to balance these figures.

As to distant cities, this is not much different in practice to the idea as originally drawn. Whatever method is used, however, would have to take account of the fact that cities would grow over time, and that some would grow faster than others; that airports would be installed in some but not all these places at different times, and that the airports would have different specifications as to, e.g., runway length. Working out a formula to randomise this in a plausible way to progress with time will actually be very challenging. One would also need to consider ETOPS ratings for the routes to each of the airports, and a reasonable means of randomising this, too.

Quite where the vehicles' graphics should go when vehicles go to portals is not an easy question: they need to be easy to locate, but not look silly all piled up on an ocean tile. No obvious solution to this currently presents itself (and doing something bespoke with the graphics, such as having them lined up outside the edge of the map, would be so difficult as to increase the work involved with completing this project by orders of magnitude).

In respect of a minimum distance, this is sensible enough, but ten times the map size seems far too high: this would mean that, for a 500km map, the nearest portal would be 5,000km away, which would be silly. A setting in simuconf.tab should suffice: I imagine that 100km would be sensible.

As to vehicles travelling between servers, this would be fantastically difficult to implement - way, way beyond my programming ability, and would give rise to possibly insuperable difficulties (e.g., what if one server is offline and the other online, or one paused and the other not; what if a player bulldozes an airport after an aircraft has been sent there, etc.). If someone could work out a practical way of doing this, and write and test all the code for it, however, I should be happy to incorporate it (so long as it would also be possible to have portals that were not other multi-player games).

[Ves]

Yes, I gues the distant cities I was talking about is more or less the same thing that you talked about.

Im not at all myself convinced that my idea would work at all, I just threw into the basket as an alternative idea. But the part about the closest xxx km being in real time, I would like to adjust to being time based as if the total traveltime of the trip is less than, say x ingame years, then the vehicle will travel in real time.
As you point out in your initial post, the airplane would make the trip usa and back in around 6+6 hours, so maybe 14 hours total with loading times included and that I think would not cause any trouble or possible exploits.

Alternatively to the exponential increase of the speed, you could also just double the speed or tripple the speed.

From the user point of view, I think it would be wise to keep it as simple as possible. No matter which version you end up with, I think it is important that the player just has to select 'a' vehicle, create the route and click go.


Another idea that just popped by (without thinking it through):
when you create a route which is like 14.000km long and intend to use old sailboats, the problem is that your vehicles will come back again in waaaaayy too many years for it to be usable, but what if your vehicles where already plotted around the map (that is the hypothetical, non existing map that is outside your game map) when you start your schedule?
That would mean that they get teleported so they get nicely spread out. This way you could have a vehicle arrive every month, and dont have to wait 37,5 ingame years for the inital vehicle to make the trip.
An example of how this could work:
You go to the depot and buy a bunch of vehicles. Then you create the schedule and set the spacing to every month (as we cannot make bigger schedules than that). In the depot window you have a button that says "calculate trip time" and that basicly looks at the schedule to check the distances between the stops, add the waiting time and comes with an estimation for how long this trip will actually take this particular convoy. It could even come with a suggestion to how many vehicles you need to fill out the spacing that you set in the schedule.
Since it registrates that you have an alien town in your schedule that is far away (not sure how to calculate that, maybe look at the previous calculated trip time?) You have two buttons:
"Go" and
"Teleport to evenly spaced positions" (I know, the button cannot be named that, I could just not think of something better at the moment)

Pressing "Go" is the current behavior, all vehicles will come out of the depot in a nice line
Pressing  the other button would result in the vehicles to be teleported to be evenly spread out in your the line.

This will result with (if you do it properly) that you can have the line between London and Australien, all boats have their correct trip distance in their odometer (teleported boats would have a calculated trip distance) and wear and tear would also be calculated extra for the teleporting vehicles.

[jamespetts]

The latter suggestion is interesting, but would, I think, be extremely difficult for players to understand. Also, I do not see how loading/unloading could work in this case, as nothing would ever actually be loaded onto these vehicles and transported (the passenger success statistics, for example, require the passengers to have reached their destination before they are recorded as having made a successful journey.

As to the idea of doubling or tripling the speed, this still does not give a formula for the correct depreciation charge for the implicit additional assets that the player gets by virtue of the speed increase, which is what I really need to try to work out.

[Ves]

It doesn't have to be difficult for the player to understand if the GUI is intuitive and tells you what you are about to do. It is, however, a groundbreaking concept for Simutrans, since we normally never teleport vehicles, and it would have to be clear that you cannot do it on milder circumstances.
Loading/unloading, maybe the vehicles that are about to teleport gets a position to teleport to, but behind the scenes travel the schedule picking up and leaving cargo in light speed, and will in the end appear with their correct load at their correct location. Obviously, the vehicles would be empty on the leg from your map toward the foreign city as your industries and passengers would have no time to react to the light speeding ships. The good/passengers from the other city however should be able to fill up the vehicles from that end.
Maybe it could be possible to mark a route as upcoming, to start a pile of good and passengers that the vehicles could pick from?

[jamespetts]

I am afraid that I am having some trouble in following your description here. I thought that you had envisaged having the actual time to traverse the route take the full time (even 37 game years if necessary), but conjure into existence vehicles had already started their route long ago at various stages of the route, but your latest post seems inconsistent with this, so I do not think that I have understood your first post correctly. Would you be able to elaborate a little on how exactly this would work?

[Ves]

You did indeed understand the first post correctly, that the vehicles would in fact take 37 years to complete a cycle. I was just thinking of a way to also have the vehicles filled with good when you click the teleport button, as they otherwise would be empty out on the map.

[jamespetts]

I still have doubts that this would work - what would stop players from saving maintenance by getting rid of all the convoys that are not on their way back? Also, actually making the system of loading with goods work sensibly would be fantastically difficult, as it would break lots of assumptions in lots of probably unknown places in the code about how this actually works. I suspect that the original idea would be much easier to implement and understand by players, but we just need to find a workable approximation for the additional depreciation cost for the assumed additional assets.

[jamespetts]

Another issue with portals that will need to be considered is this: what to do about destinations that are out of range? The longest straight line surface distance between two points on Earth is fractionally short of 20,000km (from London, the South island of New Zealand is over 19,000km away). The sensible way of setting up the portals would be for them to be distributed at random distances between 100km and 20,000km from the point on the map's edge where they reside.

A Boeing 787 "Dreamliner" has a range up to 14,140km. This is one of the longest range airliners currently in production (so far as I can find). Airliners of a previous era had a much shorter range: the Boeing 377 "Stratocruiser", a long range airliner of its day, had a maximum range of 6,760km.

There would thus be many destinations in the early years that could not be served directly by air, and some destinations even in modern times that could not be served (in reality, there are no direct London to New Zealand flights even now: see Skyscanner), no doubt because nobody has yet invented an aeroplane that can fly that far without stopping.

It would be absurd, however, for a destination 19,000km away to be reachable only by sea in 2017. In reality, of course, aircraft stop part way along their route to take on fuel and drop off and pick up passengers. This is likely to have to be simulated in order for portals to work properly. However, this is challenging. As so far conceived, each portal would simply be a tile on the edge of the map with an arbitrary distance to an imagined destination. There would be no concept of where they are relative to each other such that it would be possible to compute the distances to allow for stopping.

The internal co-ordinates used for the map in Simutrans (including Extended) are in pairs of unsigned 16-bit integers. This means that the co-ordinate ranges go from 0,0 to 65535,65535, giving a maximum possible straight line distance of 65,535 tiles, which, at 125 meters per tile, works out at 8,191.875km. Therefore, distances beyond about 8,000km cannot be represented by using co-ordinates based on the existing system. In other words, without a potentially very significant amount of work changing all of the co-ordinates to 32-bits per dimension (which is possible, but might significantly increase memory consumption: I have not calculated or tested whether this would be significant on modern machines), portal destinations cannot simply be represented as an arbitrary point on the existing map grid, beyond the borders of the populated map.

Two types of solutions present themselves: either to refactor all existing co-ordinates to 32 bits (which might be a bit much just for portals), or to invent a new co-ordinate class to be used only for portals; but that would then require potentially very complex code to map that to the ordinary co-ordinate class in an unknown number of places in the code in order to be able to compute easily total distances between a specific point on the map and the portal destination.

Either way would require very careful consideration of how the UI would work for this system. As I had originally envisaged portals, it would simply involve sending vehicles to a specially marked map-edge tile. However, this system would require something altogether more sophisticated, which would potentially considerably increase coding time to potentially prohibitive levels. I know that Ves has done some very useful UI work recently - do you have any ideas about how to deal with this?

Another complexity would be passenger generation. Previously, I had not planned for portals to generate passengers, but merely to receive them (but using the double return trick described above to give equivalent numbers as if they generated passengers). However, if vehicles were to be able to travel between remote destinations, it would be necessary to simulate a passenger (and possibly even freight) flow between those destinations to avoid the economic imbalance that would result from passengers alighting but never boarding on outbound intermediate stops. This again would add considerable complexity to the passenger generation system that the original system was designed to avoid, and I do not even begin to guess how this could work for freight.

Does anyone have any ideas as to how best to deal with these issues in a way that does not require prohibitively complex coding such as would make this feature alone take several years to implement?

[Ves]

For the sake of simplicity it would be sensible to avoid thinking of reaching further out than the furthest distance a vehicle can travel. Otherwise you could in principle create a complete new game where you can send your ships and planes between cities outside the map, never to see them again.
But if you want it to be possible, you could however make it so that when the player makes the schedule, the player only has to press the respective city tiles (see below) to add them to the schedule. A sign must, however, come up directly when trying to launch the vehicles if some of the destinations are out of range.

I think there is some concepts that must be determined. When sending your vehicles between foreign cities, you is a company on foreign soil. You don't own the infrastructure out there also there are lots of other companies, "players", out there that never ever see your map but would compete with you on those routes.
To take an example of a much smaller scale, there is a bus company in Sweden called Swebuss, which obviously operates busses. They primarily operate busses in Sweden to various destinations but have a bus line that goes from Copenhagen, through Sweden all the way to Oslo. In Denmark it also stops at the airport and in Norway it also stops 2 or 3 times before reaching Oslo. You could take the bus between the airport and Copenhagen, but you would not do that because there is much better alternatives. In Norway, few people use the bus inside Norway but I remember that as only a few.
If you consider Sweden as your visible map, the stops in Denmark and Norway would be cities outside the map. You wouldn't have to try and compete with the local traffic, because the local traffic would anyway be much better and fine tuned.

Another idea just came to my mind that would address the above:
The distant cities are already connected to each other passenger wise (maybe even good wise to some extent). Dependent on the distance between the cities, and their facilities (airport, sea route or land route) some journey time is calculated. Then if you have a passenger that wants to go to San Francisco, but your plane can only fly it to New York, your passenger will take the flight to New York provided that the entire journey time (transport from his house on your map to New York + waiting time in New York + journey time from New York to San Francisco) is within his tolerance.

GUI-wise, I guess one could reuse the existing station window and just add information from the foreign city to the existing empty space in the window.  I think it would look good if around the edge of the map there are permanent (toggleable) tooltips with the name and distance to the foreign city and perhaps population. The tile underneath the tooltip would be the one that is selected in the schedule of the vehicle and also the spot to click if you want to open the city schedule. I wouldn't know how to code that or the tooltip, I would however be able to mess around a bit with the window.
Information in the window would include such like population, exporting good and importing good, transfer time, wether there is an airport (following an earlier suggestion), landing fee etc.

Sounds good with a distribution between x and 20.000km. I think x could be as small as 1 km.

Regarding the map size, I think it is not necessary to have it more precise than 1km pr tile. Therefore a new grid that the map somehow is attached to. It makes no sense to have a map 5738km and 250 meters away
To make the map compatible with the exterior grid, you could lock the map size to 1km increments. That means you cannot have a map which is 1,125km x 1,125km. It would have to be either 1km x 1km or 2km x 2km, or 1km x 2km for that matter.

[jamespetts]

Thank you, that is most helpful. A few specific replies below.

For the sake of simplicity it would be sensible to avoid thinking of reaching further out than the furthest distance a vehicle can travel. Otherwise you could in principle create a complete new game where you can send your ships and planes between cities outside the map, never to see them again.

I suspect that you may well be right if complexity is to be kept within reasonable bounds.

[qupte]Another idea just came to my mind that would address the above:
The distant cities are already connected to each other passenger wise (maybe even good wise to some extent). Dependent on the distance between the cities, and their facilities (airport, sea route or land route) some journey time is calculated. Then if you have a passenger that wants to go to San Francisco, but your plane can only fly it to New York, your passenger will take the flight to New York provided that the entire journey time (transport from his house on your map to New York + waiting time in New York + journey time from New York to San Francisco) is within his tolerance.

This may well work.These could easily be treated in the same way as walking connexions in the path explorer, so should not add too much complexity there.

The complexity is to determine which destinations are connected to which and at what journey time(s). One possibility is to use the average journey times and ranges of lines arriving at the cities in question, but this would require considerable extra data storage and processing and be prone to anomalies depending on how the cities in question are served.

Have you any ideas as to how to estimate the connexion times robustly and simply in such a way as to avoid anomalous results? This is potentially tricky.

GUI-wise, I guess one could reuse the existing station window and just add information from the foreign city to the existing empty space in the window.

The existing station window does not allow selecting schedule destinations from its list (this would be a useful feature, but probably not worth all but a very small amount of coding time, and I suspect that it would take more than that). I had imagined that players would add portals by selecting the relevant map edge tiles (on which nothing else could be built). If there is to be no service by players between off-map destinations, then this should suffice for schedule insertion.

Looking at the station window, I suspect that it would add quite a lot of clutter to list all of a portal's features there. Also, the station window lists only the player's own stops, whereas portals would not be owned by any particular player, so, again, this would need very careful consideration.

I think it would look good if around the edge of the map there are permanent (toggleable) tooltips with the name and distance to the foreign city and perhaps population. The tile underneath the tooltip would be the one that is selected in the schedule of the vehicle and also the spot to click if you want to open the city schedule. I wouldn't know how to code that or the tooltip, I would however be able to mess around a bit with the window.
Information in the window would include such like population, exporting good and importing good, transfer time, wether there is an airport (following an earlier suggestion), landing fee etc.

That could work, provided that the tooltips were kept very short, although would require a new type of window, which I suspect would take quite a bit of coding (which would probably be more fiddly than conceptually difficult, in terms of getting each element in the window laid out sensibly and connected to the relevant data). Are you advanced enough to add new windows yet, do you think?

Regarding the map size, I think it is not necessary to have it more precise than 1km pr tile. Therefore a new grid that the map somehow is attached to. It makes no sense to have a map 5738km and 250 meters away
To make the map compatible with the exterior grid, you could lock the map size to 1km increments. That means you cannot have a map which is 1,125km x 1,125km. It would have to be either 1km x 1km or 2km x 2km, or 1km x 2km for that matter.

I am not sure that I fully understand how this would work or what you mean by this. Can you elaborate?

[laos]

This is a very fascinating discussion. A couple ideas that I hope are helpful:

In general, it sounds like the challenges come from the amount of variety and control the player gets, which is (to an extent) unrealistic, but also makes the problem all the harder to code and easier to exploit! One thing that I think could be helpful is to limit the number of player stations (or cities with stations) that can interact with a finite number of cities. Require placing a "custom house" building which, like your HQ, can be upgraded to open up various travel options based on type (carriage to ship, train, car, plane) and distances (international -> intercontinental). Admittedly this is mostly just cost of entry barriers, but it helps set limits to how many cities (which is certainly realistic) at each time period can access international cities.

Additionally, and perhaps controversially, (or against your vision of the game) you could also just set a custom list for internationally-authorized vehicles throughout the game history/timescale. This helps prevent exploitation by preventing the number of variables that have be considered. Not really a clear design process as much as adding constraints to this microcosm of the game within a simutrans map, but I will say this shouldn't be a player's sole means to making money, but rather supplement their own in-game networks, and it should be economically and strategically considered as an add-on, not a sole revenue model, in any time period.

I think a lot of this can be configured and economically scaled basically up until the jet age, especially since intercontinental travel up until the 1950s was much more exclusive than it is today. For instance, a trip from Liverpool to Boston in the mid-19th century (based on posters) comes around a month's pay for a skilled laborer, at least based on my back-of-napkin math at £6.5 pounds for steerage, scaling up to £20+. Such a trip apparently was weekly for this White Star Line ship as a convoy of two or three ships.

The hard part, and why I think this is a bit hard for simutrans, is that our passenger/city/cost scales start to get off the rails when you can send 300 people from London to New York in 6 hours, instead of a 420 hours as it took in the 1850s. Looking back at that calculated cost, inflation alone doesn't put it into perspective. If this UK Currency calculator is correct, that's only £618 in today's purchasing power off RPI alone, but worth £4,800 of labor and £7,500 of income equivalent wealth. 1880 - 2017 DJIA annualized returns are 4.8%, which would put a £6.5 investment at £1,950 today. All food for thought in the scale of this game, one that doesn't have truly comparative populations interested in traveling, not to mention the hours in a month

The game was built for local -> regional travel, not to mention a faster rate of years passing so the game doesn't play forever, so compromises were made in lengths of months, populations, travel interest, etc, including the population density scale. I'm pretty sure ours is much lower than real life's true maximum for the most densest city/business centers (50,000-100,000 per square mile as opposed to 2,500 per square mile as I see in the biggest simutrans cities in 1990) - keep in mind the island of manhattan had a peak population of 2.3 million in the 1920s (closer to the 100,000 per square mile mark) - i'm sure a lot of this was factored into pricing, but i honestly dont know exactly how you picked keyframes in pricing / cost of living, population density, pricing, likelihood to travel, and all these factors that influence the profitability of four major transportation method across 200+ years!! I do think this is what we're knocking against, not sheer issues of distances alone

I really like Ves's idea of relative distances for international cities between one another, rather than just your map. It seems like a fun way to let players be creative with strategizing routes. I also like the idea of preconfigured/preset conveys in some way to perhaps simplify and reduce exploitation risks for international/intercontinental travel. My spin on it would be to use it to remove variables and simplify aspects of this add-on travel so it supplements regional travel, and doesn't become your 'money maker' unless it's running to support a very costly transit infrastructure for, say, a large city.  Bearing in mind, as he noted, how much competition there would be and how many variables are out of your control

One last thought: This could be entirely overkill, but adding nuanced quality types to goods and passengers could make it simply harder to be profitable when using portals, and this profitability rapidly shifting (to great expense) as time progresses in the game. Again, I feel like their best use is some sort of narrowly scoped way to use them as add-on revenue opportunities, to profit from high-cost goods/passengers (business travlers, tea as you mention, etc.) and so on.

Also if you are looking for more reference points for certain goods/costs that relate to passengers and travel/shipping, let me know, happy to help dig around

[Ves]

Thank you, that is most helpful. A few specific replies below.

...
The complexity is to determine which destinations are connected to which and at what journey time(s). One possibility is to use the average journey times and ranges of lines arriving at the cities in question, but this would require considerable extra data storage and processing and be prone to anomalies depending on how the cities in question are served.
...
Have you any ideas as to how to estimate the connexion times robustly and simply in such a way as to avoid anomalous results? This is potentially tricky.

The easiest thing to do would be to assume that all cities are connected to each other. Thinking of it, there is *always* some way to go from one city to the next.
For the different jurney times between the cities, you could setup different rules:
All cities are connected by horse/bus up to X km (X being a percentage of 20.000km)
A random number decides wether the city is equipped with a harbour -> All cities with a harbour are connected by see too.
A random number decides wether the city builds/are equipped with a railway station -> All cities with a railway station up to X km (X being a percentage again) are connected by rail too.
A random number decides wether the city builds/are equipped with an airport -> All cities with an airport are connected by air too.

Whatever method that generates faster travel between two cities are choosen. No need to show multiple means of transportation.

To find the average speed of the vehicles in question, is difficult as other countries have developed other kinds of vehicles and have had other priorities. However, one could assume that in general the technology has been shared and so the vehicles should be kind of the same standard.
Take the median of all current vehicles of a given type (ie passenger rail vehicles), multiply it with with some low random factor like 0,5 to 1,0 or something similar to get variations and to simulate that it might not be a direct way.

All this doesnt have to be precise, since we cannot anyway see the "map" and only needs to have some realistic assumptions about whats happening out there. We could assume that there are some kinds of continents in the world, but since the map is completely fictional, there might be just one!

It would be good, however, to be able to make a preset list of the distant cities, so map authors can create predefined distant city name, position, its connectivity facilities etc. so you can play ie Carl's GB map and expect to find paris approximately where it is.

The existing station window does not allow selecting schedule destinations from its list (this would be a useful feature, but probably not worth all but a very small amount of coding time, and I suspect that it would take more than that). I had imagined that players would add portals by selecting the relevant map edge tiles (on which nothing else could be built). If there is to be no service by players between off-map destinations, then this should suffice for schedule insertion.

Looking at the station window, I suspect that it would add quite a lot of clutter to list all of a portal's features there. Also, the station window lists only the player's own stops, whereas portals would not be owned by any particular player, so, again, this would need very careful consideration.

I didnt mean to use the actual station window, I meant to use the layout from that window. In order to create a new window, I would look at the existing city window and see where that is defined and imitate that but with your new classes instead.
Not everything should be on the initial window, many things could go into the details window or even new other windows. Also, selecting schedule destinations, I dont understand what you mean by that?

If service between distant cities are done, why not just have the player click on the different tiles along the borders to select which cities and in which order to go to them?

That could work, provided that the tooltips were kept very short, although would require a new type of window, which I suspect would take quite a bit of coding (which would probably be more fiddly than conceptually difficult, in terms of getting each element in the window laid out sensibly and connected to the relevant data). Are you advanced enough to add new windows yet, do you think?

I have managed to create two windows by copying existing elements and giving it a new class and so on. Without any promises, I might be able.

I am not sure that I fully understand how this would work or what you mean by this. Can you elaborate?

I was just comming an issue in advance with my suggestion of having 1km tiles on the big map. If the player map is 750 meter x 750 meter, where to put it on the big map? But if the player map is 1km x 1km or 5km x 5km, it is much easier to place on the big 1km grid surrouning the player map I suppose.


It was an interresting Idea by Laos that you need customs to be able to connect to a distant city. To make sense, the first stop that a returning vehicle arrives to on your map must have a customs house connected to it, much like airport control towers work today in Extended. Those could maybe have a delaying transfer time to simulate passport control, or good declaration etc.

I would not agree on having some artificial limit on which vehicles can travel on other grounds. Maybe if rail vehicles are allowed to do it, you can run into different standards and that would make sence, but otherwise not.

[jamespetts]

Thank you both very much for your replies: the thought that you have put into this is most helpful. One thing that I think needs to be considered is that the portal feature will probably need to be coded after the maintenance costs (etc.) feature-set discussed here, firstly because the former is more important to balance, but secondly because it will not be possible to calculate a sensible number to take into account the depreciation cost of vehicles until those features are encoded. I do not know whether Andrew Traviss will get around to starting work on that before I complete the passenger and mail classes feature discussed here, which is my current major feature project, but, if he does not, I will have to start coding it myself and suggest to Andrew other useful projects on which he might work, including possibly this one.

As to the various ideas, I deal with them in turn.

Require placing a "custom house" building which, like your HQ, can be upgraded to open up various travel options based on type (carriage to ship, train, car, plane) and distances (international -> intercontinental). Admittedly this is mostly just cost of entry barriers, but it helps set limits to how many cities (which is certainly realistic) at each time period can access international cities.

This is an interesting idea, especially if coupled with Ves's suggestion of this increasing the passenger/goods transfer/transhipment time. However, this would be costly to code (and require a number of new building graphics as well as additional code), and it is not clear why this is really necessary for game balance. It might be possible to add it later in much the same way as airport control towers were added later.

Additionally, and perhaps controversially, (or against your vision of the game) you could also just set a custom list for internationally-authorized vehicles throughout the game history/timescale. This helps prevent exploitation by preventing the number of variables that have be considered. Not really a clear design process as much as adding constraints to this microcosm of the game within a simutrans map, but I will say this shouldn't be a player's sole means to making money, but rather supplement their own in-game networks, and it should be economically and strategically considered as an add-on, not a sole revenue model, in any time period.

I am not clear on what sort of exploitation that this could prevent, nor on what real life dynamic that this would be simulating. Can you elaborate?

I think a lot of this can be configured and economically scaled basically up until the jet age, especially since intercontinental travel up until the 1950s was much more exclusive than it is today. For instance, a trip from Liverpool to Boston in the mid-19th century (based on posters) comes around a month's pay for a skilled laborer, at least based on my back-of-napkin math at £6.5 pounds for steerage, scaling up to £20+. Such a trip apparently was weekly for this White Star Line ship as a convoy of two or three ships.

The hard part, and why I think this is a bit hard for simutrans, is that our passenger/city/cost scales start to get off the rails when you can send 300 people from London to New York in 6 hours, instead of a 420 hours as it took in the 1850s. Looking back at that calculated cost, inflation alone doesn't put it into perspective. If this UK Currency calculator is correct, that's only £618 in today's purchasing power off RPI alone, but worth £4,800 of labor and £7,500 of income equivalent wealth. 1880 - 2017 DJIA annualized returns are 4.8%, which would put a £6.5 investment at £1,950 today. All food for thought in the scale of this game, one that doesn't have truly comparative populations interested in traveling, not to mention the hours in a month

The significance of the cost of international travel should be dealt with by the passengers and mail classes feature, which is my current major feature project. When that is implemented, only a fraction of passengers will be able to afford to travel in vehicles marked as requiring a higher class, and the vehicles could then be balanced so that very long distance journeys are not profitable with earlier vehicles (e.g. older airliners) unless the cost of travel is set so that only a few people can afford to travel. Steerage on a ship, for example, might be "low" rather than "very low", and in any event, the huge travel time involved would greatly limit passengers' willingness to take such a journey. 

Note also that players will need to make local/national transport work well in order to have a profitable international port/airport, as the passengers/mail/goods need to be able to get to the port/airport in the first place, and only a few will be in walking distance.

The game was built for local -> regional travel, not to mention a faster rate of years passing so the game doesn't play forever, so compromises were made in lengths of months, populations, travel interest, etc, including the population density scale. I'm pretty sure ours is much lower than real life's true maximum for the most densest city/business centers (50,000-100,000 per square mile as opposed to 2,500 per square mile as I see in the biggest simutrans cities in 1990) - keep in mind the island of manhattan had a peak population of 2.3 million in the 1920s (closer to the 100,000 per square mile mark) - i'm sure a lot of this was factored into pricing, but i honestly dont know exactly how you picked keyframes in pricing / cost of living, population density, pricing, likelihood to travel, and all these factors that influence the profitability of four major transportation method across 200+ years!! I do think this is what we're knocking against, not sheer issues of distances alone

The city growth mechanism remains at present largely unchanged from Standard and in need of calibration/change. That would, however, be another major feature project that would take many months by itself; but it is planned to have cities growing in realistic ways (i.e. by reference to local transport quality) and having realistic densities.

I am not sure, however, how densities in and of themselves are critical for international transport to balance more than they are for local transport to balance; can you elaborate?

I really like Ves's idea of relative distances for international cities between one another, rather than just your map. It seems like a fun way to let players be creative with strategizing routes. I also like the idea of preconfigured/preset conveys in some way to perhaps simplify and reduce exploitation risks for international/intercontinental travel. My spin on it would be to use it to remove variables and simplify aspects of this add-on travel so it supplements regional travel, and doesn't become your 'money maker' unless it's running to support a very costly transit infrastructure for, say, a large city.  Bearing in mind, as he noted, how much competition there would be and how many variables are out of your control

I am not sure exactly what you mean by this; can you elaborate? Do you just mean that players should not be able to fly/sail between off-map cities, but that there should be assumed connexions between them as Ves suggests?

One last thought: This could be entirely overkill, but adding nuanced quality types to goods and passengers could make it simply harder to be profitable when using portals, and this profitability rapidly shifting (to great expense) as time progresses in the game. Again, I feel like their best use is some sort of narrowly scoped way to use them as add-on revenue opportunities, to profit from high-cost goods/passengers (business travlers, tea as you mention, etc.) and so on.

This seems very similar to the passenger/mail classes feature that I am currently working to implement; have you seen that discussion?

Also if you are looking for more reference points for certain goods/costs that relate to passengers and travel/shipping, let me know, happy to help dig around

If you have any useful historical pricing information, it would be very useful if you could post it on this thread, where I like to collect information of that sort.

The easiest thing to do would be to assume that all cities are connected to each other. Thinking of it, there is *always* some way to go from one city to the next.
For the different jurney times between the cities, you could setup different rules:
All cities are connected by horse/bus up to X km (X being a percentage of 20.000km)
A random number decides wether the city is equipped with a harbour -> All cities with a harbour are connected by see too.
A random number decides wether the city builds/are equipped with a railway station -> All cities with a railway station up to X km (X being a percentage again) are connected by rail too.
A random number decides wether the city builds/are equipped with an airport -> All cities with an airport are connected by air too.

Whatever method that generates faster travel between two cities are choosen. No need to show multiple means of transportation.

To find the average speed of the vehicles in question, is difficult as other countries have developed other kinds of vehicles and have had other priorities. However, one could assume that in general the technology has been shared and so the vehicles should be kind of the same standard.
Take the median of all current vehicles of a given type (ie passenger rail vehicles), multiply it with with some low random factor like 0,5 to 1,0 or something similar to get variations and to simulate that it might not be a direct way.

All this doesnt have to be precise, since we cannot anyway see the "map" and only needs to have some realistic assumptions about whats happening out there. We could assume that there are some kinds of continents in the world, but since the map is completely fictional, there might be just one!

Would we be looking here at the theoretical maximum speeds of current vehicles, or their actual in-service speeds? The latter can be considerably lower than the former, especially for steam trains.

I wonder whether it might be better to simplify this even more and make it more abstract, and simply have three hypothetical connexion types: land, sea and air, with a random average speed picked from a range of average speeds specified in a configuration file that vary with the years in much the same way as the speed bonus speeds do now. We could even re-use the speed bonus data to do this. We could have rules for a maximum distance for land transport and a minimum distance for air transport, as well as requiring both places to have an airport if land travel is to be used.

Indeed, in this system, we might have something closer to your original idea of "distant cities", with a long list of cities with positions on a hypothetical super-map that grow and can, in time, acquire ports or airports; perhaps the cities can be randomised as to whether they have coastal access at the beginning so that some cities can never acquire a port. All the cities have connexions to one another based on the above rules, although these might not end up being direct connexions as there might be land-locked cities far away that could only be reached by travelling over land to a port city and then by sea to another port city before travelling over land again to the destination land locked city).

It would be good, however, to be able to make a preset list of the distant cities, so map authors can create predefined distant city name, position, its connectivity facilities etc. so you can play ie Carl's GB map and expect to find paris approximately where it is.

An interesting idea, although, as with the customs house, this might considerably increase coding time for a somewhat marginal value. Something that could be added later, perhaps. However, a different list of city names for off-map cities would be easy enough and probably required to make them seem distinctive.

Alternatively, there might be some tool to edit "distant cities" in-game by the public player, although this might also be tricky to implement.

I didnt mean to use the actual station window, I meant to use the layout from that window. In order to create a new window, I would look at the existing city window and see where that is defined and imitate that but with your new classes instead.

Ahh, I see, this makes much more sense. This does seem sensible.

Not everything should be on the initial window, many things could go into the details window or even new other windows. Also, selecting schedule destinations, I dont understand what you mean by that?

This also makes sense. As to selecting schedule destinations, I mean the process whereby a player is creating a schedule and selecting individual destinations to go on the schedule. At present, a player must click an actual tile on the map, not just the name of the station in the stations list window.

If service between distant cities are done, why not just have the player click on the different tiles along the borders to select which cities and in which order to go to them?

This could work. We need to think what should happen if a player selects more than one portal in sequence, however, given the intended limitations discussed above.

I have managed to create two windows by copying existing elements and giving it a new class and so on. Without any promises, I might be able.

It would be excellent if you were able to assist. Your work on GUI is capable of considerably increasing the speed with which these features can be produced. You will have some time before you need to start on this in any event as there are some more things to do before it will be time to start work on this.

I was just comming an issue in advance with my suggestion of having 1km tiles on the big map. If the player map is 750 meter x 750 meter, where to put it on the big map? But if the player map is 1km x 1km or 5km x 5km, it is much easier to place on the big 1km grid surrouning the player map I suppose.

In reality, I think that it would be much easier to code if the meters per tile value were to remain the same: using 32 bit integers, these numbers can go high enough for an earth sized planet at 125m/tile.


Edit/addendum: Another important issue to consider is geography. If we imagine that the "distant cities" are located at actual grid co-ordinates on a super-map of which the in-game map is a part, then it does not really make sense to have a single point of entry/exit on the game map to this place, as the shortest route to this position will change depending on where on the in-game map that a journey starts. Imagine, for example, a destination due north of the middle of the game map. A ship/aircraft leaving from the far west of the game map will have a journey to that point that involves leaving the map at a point considerably to the west of a ship/aircraft leaving from the far east of the map, which would have a point of exit to the east of a vehicle travelling from due south of the destination. Also, there is no easy algorithm for relating these entry/exit points to the hypothetical grid co-ordinates. The original idea, not involving these places having an actual grid location, would work well with having points of entry/exit assigned entirely at random, but this cannot work with the system as it is now evolving to be designed.

The existing route-finding system cannot be used, as that checks each individual tile, and there would not be data for individual tiles outside the map. It might be that some adaptation of the way in which aircraft find routes could be used, but this is not clear as I am not sure how aircraft route finding works, as I have never altered this part of the code. Any ideas on how algorithmically to implement this would be welcome.

Another issue is how, if there are not to be map edge portals, players are to interact with this for the schedules, as discussed above. I cannot think of anything at present other than to have players add the distant destinations by selecting them from the list of such destinations. If anyone has any easy to implement, robust ideas as to how better to do this, I should be interested.

On the theme of geography is also the need to define land masses and oceans. This is important to ensure that the data in individual foreign destinations are coherent (e.g., sets of destinations clustered together between which land travel is possible, but where land travel outside those sets is not possible). It is also necessary to have some way of defining land masses and oceans in order for certain parameters relating to air travel to make sense: supersonic flight is possible only over oceans, but trans-oceanic flight requires either aircraft with 3 or more engines, or a suitable ETOPS rating. It is necessary for data for these to be coherent so that there is not a situation where, e.g., it is possible to fly supersonically to one destination that is a 30 minute land journey away from another to which it is not possible to fly supersonically.

How to achieve this with a simple and robust algorithm is not entirely straightforward. One might try to define areas (rectangles may well suffice) on the super-map of land masses: each destination on that land mass would have a ground connexion to each other destination on the land mass but not to any destination outside the land mass. The land masses could have names of destinations chosen from different lists, and supply and demand goods of different types. Quite how to write an algorithm to produce these quickly in ways that do not overlap is not entirely clear to me at present.

Destinations outside land masses, simulating minor outlying islands, could also be generated: these would always have a port and have no land connexion to any other destination, and would always assume an ocean crossing for the purposes of air travel (although supersonic travel would add great complexity; a journey from London to Hawaii, for instance, would involve a large spell of over-land travel which would be very complex to simulate here; one wonders whether one could simply dispense with simulating this without significant economic difficulty given the marginal economics of supersonic flight). Minor outlying islands might well also tend to have a much smaller population (i.e. visitor demand) than continental destinations.



Goods supply/demand is also complex; the current system used for industries could not be replicated exactly. Perhaps a system in which all foreign destinations supplying goods were treated as if they were primary industries for those goods and consumer industries for export goods demanded?

Also, finding a robust way of simulating changes in goods demand/production among these foreign destinations is likely to be complex. Any ideas as to how to achieve this without excessive complexity would be much appreciated.

[Ves]

This is an interesting idea, especially if coupled with Ves's suggestion of this increasing the passenger/goods transfer/transhipment time. However, this would be costly to code (and require a number of new building graphics as well as additional code), and it is not clear why this is really necessary for game balance. It might be possible to add it later in much the same way as airport control towers were added later.

One thing to consider with customs houses is that you might already be simulating multiple countries on your map. Then being forced to build a customs house to connect to distant cities might feel inconsistent.

Would we be looking here at the theoretical maximum speeds of current vehicles, or their actual in-service speeds? The latter can be considerably lower than the former, especially for steam trains.

I wonder whether it might be better to simplify this even more and make it more abstract, and simply have three hypothetical connexion types: land, sea and air, with a random average speed picked from a range of average speeds specified in a configuration file that vary with the years in much the same way as the speed bonus speeds do now. We could even re-use the speed bonus data to do this. We could have rules for a maximum distance for land transport and a minimum distance for air transport, as well as requiring both places to have an airport if land travel is to be used.

Yes it might be better and easier to just assign speed for different eras and methods manually in simuconf.tab.

Indeed, in this system, we might have something closer to your original idea of "distant cities", with a long list of cities with positions on a hypothetical super-map that grow and can, in time, acquire ports or airports; perhaps the cities can be randomised as to whether they have coastal access at the beginning so that some cities can never acquire a port. All the cities have connexions to one another based on the above rules, although these might not end up being direct connexions as there might be land-locked cities far away that could only be reached by travelling over land to a port city and then by sea to another port city before travelling over land again to the destination land locked city).

Sounds very appealing! Your passengers and possibly also goods would still want to go to those places but you as a player can only connect to whatever you can connect to, leaving the rest to the local transports.

You will have some time before you need to start on this in any event as there are some more things to do before it will be time to start work on this.

Excellent, then I can practice a bit more

In reality, I think that it would be much easier to code if the meters per tile value were to remain the same: using 32 bit integers, these numbers can go high enough for an earth sized planet at 125m/tile.

Ok.

Edit/addendum: Another important issue to consider is geography. If we imagine that the "distant cities" are located at actual grid co-ordinates on a super-map of which the in-game map is a part, then it does not really make sense to have a single point of entry/exit on the game map to this place, as the shortest route to this position will change depending on where on the in-game map that a journey starts. Imagine, for example, a destination due north of the middle of the game map. A ship/aircraft leaving from the far west of the game map will have a journey to that point that involves leaving the map at a point considerably to the west of a ship/aircraft leaving from the far east of the map, which would have a point of exit to the east of a vehicle travelling from due south of the destination. Also, there is no easy algorithm for relating these entry/exit points to the hypothetical grid co-ordinates. The original idea, not involving these places having an actual grid location, would work well with having points of entry/exit assigned entirely at random, but this cannot work with the system as it is now evolving to be designed.

The existing route-finding system cannot be used, as that checks each individual tile, and there would not be data for individual tiles outside the map. It might be that some adaptation of the way in which aircraft find routes could be used, but this is not clear as I am not sure how aircraft route finding works, as I have never altered this part of the code. Any ideas on how algorithmically to implement this would be welcome.

I was thinking of this, and would it be easier if the vehicle traveled just straight north and then exited the map at whatever tile is straight north? Or if the distant city tile is on the east side of the map, the vehicles would just turn east when possible and exit the map.

Another issue is how, if there are not to be map edge portals, players are to interact with this for the schedules, as discussed above. I cannot think of anything at present other than to have players add the distant destinations by selecting them from the list of such destinations. If anyone has any easy to implement, robust ideas as to how better to do this, I should be interested.

What about adding the cities to the schedule by clicking on the corresponding tile around the edge of the map?

On the theme of geography is also the need to define land masses and oceans. This is important to ensure that the data in individual foreign destinations are coherent (e.g., sets of destinations clustered together between which land travel is possible, but where land travel outside those sets is not possible). It is also necessary to have some way of defining land masses and oceans in order for certain parameters relating to air travel to make sense: supersonic flight is possible only over oceans, but trans-oceanic flight requires either aircraft with 3 or more engines, or a suitable ETOPS rating. It is necessary for data for these to be coherent so that there is not a situation where, e.g., it is possible to fly supersonically to one destination that is a 30 minute land journey away from another to which it is not possible to fly supersonically.

How to achieve this with a simple and robust algorithm is not entirely straightforward. One might try to define areas (rectangles may well suffice) on the super-map of land masses: each destination on that land mass would have a ground connexion to each other destination on the land mass but not to any destination outside the land mass. The land masses could have names of destinations chosen from different lists, and supply and demand goods of different types. Quite how to write an algorithm to produce these quickly in ways that do not overlap is not entirely clear to me at present.

Destinations outside land masses, simulating minor outlying islands, could also be generated: these would always have a port and have no land connexion to any other destination, and would always assume an ocean crossing for the purposes of air travel (although supersonic travel would add great complexity; a journey from London to Hawaii, for instance, would involve a large spell of over-land travel which would be very complex to simulate here; one wonders whether one could simply dispense with simulating this without significant economic difficulty given the marginal economics of supersonic flight). Minor outlying islands might well also tend to have a much smaller population (i.e. visitor demand) than continental destinations.

Although that sounds really cool, I think it might easily get too complicated.
If you do make some rectangles big and small out in the world, giving them names and place cities on them, some on the shore, some in the middle (and now I'm adding complexity, hehe :p ) some towards the middle but on river banks so you can sail ships to them, I think that would suffice. Then the game knows that those are at least connected by road, maybe rail (and possibly port and airport too). All that is needed to present to the player is the continent name which will be visible under the city name in the info window.

The Concorde not allowing to travel at supersonic speed above land masses I think is a one case and could imo be ignored. There are plenty of other reasons as to why the Concorde didn't work out and also, you might end up with a world with no open sea at all, and then the Concorde would be worthless.

Goods supply/demand is also complex; the current system used for industries could not be replicated exactly. Perhaps a system in which all foreign destinations supplying goods were treated as if they were primary industries for those goods and consumer industries for export goods demanded?

Also, finding a robust way of simulating changes in goods demand/production among these foreign destinations is likely to be complex. Any ideas as to how to achieve this without excessive complexity would be much appreciated.

I have no good suggestion for the goods really. Only that it could work under the same principles, but take much longer time and have some more restrictions like connectivity.

[jamespetts]

One thing to consider with customs houses is that you might already be simulating multiple countries on your map. Then being forced to build a customs house to connect to distant cities might feel inconsistent.

Yes, although that depends on how one conceptualises the game map, I suppose.

Yes it might be better and easier to just assign speed for different eras and methods manually in simuconf.tab.

It would be much easer to do this in a bespoke .tab file as with the speed bonus than in simuconf.tab, but that is a minor detail.

Sounds very appealing! Your passengers and possibly also goods would still want to go to those places but you as a player can only connect to whatever you can connect to, leaving the rest to the local transports.

Yes, in principle this seems to be the most workable way of doing this.

Excellent, then I can practice a bit more

I shall look forward to the result of your practising!

I was thinking of this, and would it be easier if the vehicle traveled just straight north and then exited the map at whatever tile is straight north? Or if the distant city tile is on the east side of the map, the vehicles would just turn east when possible and exit the map.
What about adding the cities to the schedule by clicking on the corresponding tile around the edge of the map?

The trouble is, though, that heading straight north would not be the shortest route to the foreign destination from anywhere except due south of it. From anywhere else, the shortest route would either be north-west or north-east and the point at which that straight line crosses the edge of the map would differ depending on the origin point on the in-game map. There would therefore not be a single "corresponding tile" around the edge of the map for any given foreign destination.

Although that sounds really cool, I think it might easily get too complicated.
If you do make some rectangles big and small out in the world, giving them names and place cities on them, some on the shore, some in the middle (and now I'm adding complexity, hehe :p ) some towards the middle but on river banks so you can sail ships to them, I think that would suffice. Then the game knows that those are at least connected by road, maybe rail (and possibly port and airport too). All that is needed to present to the player is the continent name which will be visible under the city name in the info window.

I was not thinking of anything more complex than this, but rather how, algorithmically, to make even this work (and have a way of checking that these rectangles are not overlapping, etc.).

The Concorde not allowing to travel at supersonic speed above land masses I think is a one case and could imo be ignored. There are plenty of other reasons as to why the Concorde didn't work out and also, you might end up with a world with no open sea at all, and then the Concorde would be worthless.

It is not just Concorde that is important, though: it is all twin engined aircraft. They can only fly over long stretches of ocean (or wilderness) with a suitable ETOPS rating (and, before 1986, there were no such ratings, meaning that they always had to be within 60 minutes of a diversion airport). Thus, it is important to know whether any given destination requires an over-sea or an over-land route to reach to know not just whether it is possible to fly supersonically, but also to know whether it is possible to fly a twin engined aircraft to it.

I have no good suggestion for the goods really. Only that it could work under the same principles, but take much longer time and have some more restrictions like connectivity.

What do you mean by "more restrictions like connectivity"?

[Ves]

The trouble is, though, that heading straight north would not be the shortest route to the foreign destination from anywhere except due south of it. From anywhere else, the shortest route would either be north-west or north-east and the point at which that straight line crosses the edge of the map would differ depending on the origin point on the in-game map. There would therefore not be a single "corresponding tile" around the edge of the map for any given foreign destination.

I mean that the destination probably is so far away from the map you are playing, so you wouldnt notice the difference in course needed. Just look at real world Great Britain. In practice if we look away from airways, in order to go to New york, all planes goes west. There would not be the big difference in course if it took of from the southernmost airport or the northernmost airport. Obviously that is not completely true in real life since we have airways and airspaces etc.

What do you mean by "more restrictions like connectivity"?

Handling goods is way more clumpsy than handling passengers. Passengers will automatically just seek information and walk towards their destination while goods will just sit there do nothing to get towards its destination.
Restrictions like connectivity means that not all cities are connected to each other goods wise. Most cities have the easy goods connected like mail, crates and containers while tank and bulk transport might be only transported from the producing city (or the importing city) to its closest neighbours.
Since good types can be defined differently, the good types should also get an option in the simuconf.tab to determine how "difficult" it is to transport, and by that adjusting its connectivity.

[jamespetts]

I mean that the destination probably is so far away from the map you are playing, so you wouldnt notice the difference in course needed. Just look at real world Great Britain. In practice if we look away from airways, in order to go to New york, all planes goes west. There would not be the big difference in course if it took of from the southernmost airport or the northernmost airport. Obviously that is not completely true in real life since we have airways and airspaces etc.

On a large map, a destination would have to be extremely far away for the optimum departure tile to be identical from all origin points. Given that it should be possible for foreign destinations to be as close as 100km away (the distance between Dover and Calais is only 33km), this does not seem feasible.

Handling goods is way more clumpsy than handling passengers. Passengers will automatically just seek information and walk towards their destination while goods will just sit there do nothing to get towards its destination.
Restrictions like connectivity means that not all cities are connected to each other goods wise. Most cities have the easy goods connected like mail, crates and containers while tank and bulk transport might be only transported from the producing city (or the importing city) to its closest neighbours.
Since good types can be defined differently, the good types should also get an option in the simuconf.tab to determine how "difficult" it is to transport, and by that adjusting its connectivity.

It is difficult to think of a workable algorithm for this. If we imagine a very long list of foreign destinations, for any given foreign destination to which it is desired to export goods, for example, how would the algorithm decide whether it would be connected in terms of cement to a city with a port on the same continent?

Also, one other thing to consider with goods: on-map industries have specific contracts with other industries: they only demand goods from the specific industries to which they are connected. How might this work for off-map industries?

[Vladki]

Uh oh, it became TLDR for me...
But I have one idea. What about having more maps in one game? There would be a map of maps telling their relative positions, and you could send ships and planes between maps. This would solve all questions dealing with the behavior of the remote destination. It would be just a normal map as usual.

If multiple maps would be a problem, then what about one map, which has defined areas (islands, continents) where normal rules apply, and the rest of map would be void or empty deep sea, where nothing can be done. Not even oil rigs, only planes and ships crossing the sea. Then, the memory consumption coul be reduced even for very large map.

[jamespetts]

Thank you for your thoughts; apologies that the discussion has become quite involved: it is a complex topic getting the balance right for these things.

Uh oh, it became TLDR for me...
But I have one idea. What about having more maps in one game? There would be a map of maps telling their relative positions, and you could send ships and planes between maps. This would solve all questions dealing with the behavior of the remote destination. It would be just a normal map as usual.

It is not clear what the advantage would be of multiple maps over having one huge map (and the problem with one huge map is that it would be far beyond what any computer could cope with). The idea is to have a system of remote destinations that only adds a very small amount of additional memory and computational power.

If multiple maps would be a problem, then what about one map, which has defined areas (islands, continents) where normal rules apply, and the rest of map would be void or empty deep sea, where nothing can be done. Not even oil rigs, only planes and ships crossing the sea. Then, the memory consumption coul be reduced even for very large map.

That is an interesting idea, but would have three problems. First of all, actually setting up the map to work in this way would take a huge amount of effort as it would require altering a number of fundamental parts of the code the current working of which is assumed in a huge number of places in the code that would be extremely hard to find. Secondly, it would be very difficult for players to navigate this vast wilderness (imagine trying to scroll from London to Aukland in Simutrans at 125m/tile with no distinguishing features on the outer parts of the map). Thirdly, this would not solve the original problem relating to the timing: a ship would still take 375 game years to make a one way trip to Australia.

[Vladki]

I know it won't solve the timing problem. I don't know how to solve it.

The idea with multiple smaller maps is that they will consume significantly less resources than one huge map, while keeping the game play unchanged.

Scrolling between continents would have to be done using minimap...

[jamespetts]

Trying to find ways of solving the timing issue, there are some good data here about the leasing versus capital costs of various secondhand airliners (in 2015).

The A320, for example, would cost US$44m for a newer secondhand unit, which would cost US$320,000 per month to lease. The ATR-72 would cost US$21m to purchase and US$185,000 to lease. That is a ratio of 0.0072 monthly lease to capital purchase costs for the A319 and 0.0088 lease to purchase cost for the ATR-72.  Many of the others seem to range from 0.008 - 0.015.

The narrowness of that range suggests that it is possible to arrive at a good figure from the data: one might take it at 0.01 (i.e. 1%) of the current value of the vehicle in question. So, if, for example, an aircraft had a current value of 100,000 SimuCents, for every 6.4 hours (i.e. 1 month) of time saved by not taking the full journey time, the player would pay an acceleration fee of 1,000 SimuCents.

To solve the problem of players who might not want the frequency implied by acceleration because the route does not demand it, the acceleration could be optional. The default may well be for the convoy to take the full time, but with an option to accelerate so as to cap the route at any given number of in-game hours.

So, for example, a sea voyage that would last in real time 37.5 in-game years (2,880 hours) could be accelerated to take no more than 1 in-game month (6.4 hours), but at a fee of 28.736x the current value of the ship (making a fee of 2,873,600 SimuCents if the ship were worth 100,000 SimuCents).

A flight that would normally last 7.5 hours (1.17 game months) could be flown in real time, or accelerated to take no more than, say, 4 hours. The acceleration of 3.5 hours (or 0.546875 of a month) would cost 0.00546875 of the aircraft's current value, or 546.87 SimuCentsfor an aircraft currently worth 100,000 SimuCents.

I should note that I envisage that the optional acceleration would only have effect for that time beyond the map border, not whilst the convoy is within the confines of the map.

This would need a little more UI work than acceleration by default; is that something that you would be happy with if you were to work on the UI of this project, Ves?

[Ves]

Yes I will try my best to help out with the GUI!

Have you decided to go with accelerated vehicles outside the map?

Are the players supposed to determine themself the acceleration?

[jamespetts]

I have not made any final decisions yet, as I may have other thoughts (or others may make better suggestions) between now and the time for implementation, and there is never much utility in making final decisions before implementation begins. Implementation of this feature will have to wait for (1) the passenger and mail classes feature (on which I am working now); (2) the maintenance features; (3) inflation; and (4) pakset balancing (not counting bug fixing in the meantime, which carries on between these works).

However, my current preferred option is the idea of time acceleration. This is not the same as vehicle acceleration: this would work by detaining the vehicle on the map edge tile in a special "in foreign territory" state for a fixed time based on the calculated off map journey time, with a cap on that time that can be set by the player - for a cost (calculated as described above). Does this make sense?

Thank you very much for offering to help with the GUI - this will be very much appreciated when it comes time to implement this feature.

[zook2]

Hi,

I'm late to the discussion but I find it quite interesting. I needed some visualization of the issue, so I drew up a little schematic. Is that roughly what the current feature might look like?

- Only sea/air connections to off-map cities are allowed, but off-map cities can have land connections to each other. A passenger wishing to go to San Francisco could take the boat to NY, if that's all that the player offers. Later the player could add a direct flight to SF, though, if the plane has a range of 5500km.

- Freight could go from Moscow to Copenhagen and be picked up by a player's ship.

[jamespetts]

Interesting diagram! You are not too late, relatively speaking, as actually implementing this is some way off due to the number of things that need to be done first.

And, yes, that is more or less what we have in mind at present.

[DrSuperGood]

So into the pakset one would create a virtual wrapped map of a planet and then place the game world somewhere on that map for computing portal interactions? Or would the portal interaction map be set up as a tree for each game world?