Author Topic: Portals  (Read 3243 times)

0 Members and 1 Guest are viewing this topic.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Portals
« on: May 14, 2017, 09:25:19 PM »
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Yona-TYT

Re: Portals
« Reply #1 on: May 15, 2017, 12:53:10 AM »
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. ;)

Offline Vladki

Re: Portals
« Reply #2 on: May 15, 2017, 06:51:18 AM »
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?




Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #3 on: May 15, 2017, 12:04:52 PM »
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.

Quote from: 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?

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).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Jando

Re: Portals
« Reply #4 on: May 19, 2017, 12:52:36 PM »
... (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.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #5 on: May 19, 2017, 01:03:33 PM »
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Jando

Re: Portals
« Reply #6 on: May 19, 2017, 03:14:47 PM »
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. :)

Online Ves

Re: Portals
« Reply #7 on: May 19, 2017, 05:58:51 PM »
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.

Offline Vladki

Re: Portals
« Reply #8 on: May 19, 2017, 06:43:32 PM »
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...

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #9 on: May 20, 2017, 07:59:51 PM »
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).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Ves

Re: Portals
« Reply #10 on: May 20, 2017, 11:22:42 PM »
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.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #11 on: May 20, 2017, 11:57:31 PM »
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Ves

Re: Portals
« Reply #12 on: May 21, 2017, 12:19:07 AM »
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?

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #13 on: May 21, 2017, 12:32:35 AM »
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Ves

Re: Portals
« Reply #14 on: May 21, 2017, 08:20:58 AM »
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.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #15 on: May 21, 2017, 11:54:07 AM »
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #16 on: June 02, 2017, 09:39:53 PM »
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Ves

Re: Portals
« Reply #17 on: June 02, 2017, 11:34:57 PM »
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.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #18 on: June 03, 2017, 12:35:20 AM »
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.

Quote
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.

Quote
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?

Quote
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline laos

Re: Portals
« Reply #19 on: June 03, 2017, 07:17:52 AM »
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 :)

Online Ves

Re: Portals
« Reply #20 on: June 03, 2017, 09:32:17 AM »
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.

Quote
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?

Quote
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.

Quote
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.
« Last Edit: June 03, 2017, 10:02:09 AM by Ves »

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #21 on: June 03, 2017, 11:59:57 AM »
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.

Quote
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?

Quote
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.

Quote
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?

Quote
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?

Quote
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?

Quote
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).

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.
« Last Edit: June 03, 2017, 01:11:08 PM by jamespetts »
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Ves

Re: Portals
« Reply #22 on: June 03, 2017, 05:29:15 PM »

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.


Quote
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.

Quote
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.





Quote
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 :)

Quote
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.

Quote
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.

Quote
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?

Quote
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.

Quote
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.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #23 on: June 03, 2017, 09:19:38 PM »
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.

Quote
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.

Quote
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.


Quote
Excellent, then I can practice a bit more :)

I shall look forward to the result of your practising!

Quote
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.


Quote
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.).

Quote
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.

Quote
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"?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Ves

Re: Portals
« Reply #24 on: June 04, 2017, 09:16:42 AM »
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.

Quote
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.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #25 on: June 04, 2017, 10:09:08 AM »
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.

Quote
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Vladki

Re: Portals
« Reply #26 on: June 04, 2017, 06:47:19 PM »
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.




Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #27 on: June 04, 2017, 07:20:12 PM »
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.

Quote
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Vladki

Re: Portals
« Reply #28 on: June 04, 2017, 07:44:08 PM »
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...




Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #29 on: June 18, 2017, 03:02:56 PM »
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Online Ves

Re: Portals
« Reply #30 on: June 18, 2017, 08:14:52 PM »
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?

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #31 on: June 18, 2017, 08:51:43 PM »
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline zook2

Re: Portals
« Reply #32 on: August 18, 2017, 08:46:35 PM »
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.
« Last Edit: August 18, 2017, 08:58:47 PM by zook2 »

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #33 on: August 18, 2017, 08:59:43 PM »
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: Portals
« Reply #34 on: August 19, 2017, 02:17:12 AM »
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?

Offline zook2

Re: Portals
« Reply #35 on: August 19, 2017, 04:20:21 AM »
I assumed the tree would be randomized; note that I pulled the distances out of my made up the distances. But I guess there's no reason why one couldn't load an XML file with a pre-made city list instead of random generation at startup.

Offline zook2

Re: Portals
« Reply #36 on: August 19, 2017, 05:04:39 AM »
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.

Store the compass direction for each distant city (only required for the first city in each branch, like New York in my above example map). Then divide each map edge (e.g. west) into four quarters to get three equidistant portals to New York. Assume that the distance to NY is 3000km for all of them, but note that it now makes a difference which portal you send the plane to. Also, the number of portals could depend on map size.

You could have more than one city branch for each map edge. For example, NY could be North-West at a distance of 3000km, Havana could be South-West, and Baltimore could be West. Then you could simply rule that the northernmost portal is only 2800km from NY, the middle one 3000km, and the southern portal 3200km (see the attached image).

If you're a stickler for correctness then calculate the distances. You know the length of the map edge, the compass direction to NY and the distance to New York. Just apply some fancy trigonometry functions.

Now if you look at the image, you'll see that we have three western portals, two of which are land-locked, and we only allow ships and planes to leave the map. That gives us two air-travel-only portals. What if our game map has no water on the western map edge? Do we allow ships to travel via a portal on the southern map edge to go to NY (with an arbitrary distance penalty)?

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #37 on: August 19, 2017, 01:16:43 PM »
Thank you for your interesting thoughts. I have not yet resolved finally how to implement this, but my current leaning is towards a system that does not really involve portals, as such, at all, but rather a range of points on a hypothetical super-map of which the real game map is in the centre delineated by co-ordinates. I had not considered having the map wrapped, as I am not sure whether there is an algorithm that can do this efficiently with lots of pathfinding using only co-ordinates as nodes and simulated edges between those nodes. If wrapping can be done without too much difficulty, this would be preferable to simulating Flatland.

With this system, it should be possible for vehicles to calculate distances and directions to distant, off-map locations using the existing pathfinding system and system for calculating distances without having to use complex branching logic inside the pathfinding code to have different logic for pathfinding inside the map compared to pahtfinding outside the map. I have not, however, considered fully how this might work with the current 16-bit limitation on co-ordinates, which might make this rather more complex.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: Portals
« Reply #38 on: August 19, 2017, 02:56:52 PM »
Quote
Thank you for your interesting thoughts. I have not yet resolved finally how to implement this, but my current leaning is towards a system that does not really involve portals, as such, at all, but rather a range of points on a hypothetical super-map of which the real game map is in the centre delineated by co-ordinates. I had not considered having the map wrapped, as I am not sure whether there is an algorithm that can do this efficiently with lots of pathfinding using only co-ordinates as nodes and simulated edges between those nodes. If wrapping can be done without too much difficulty, this would be preferable to simulating Flatland.
Wrapping would be achieved for such algorithms by translating all wrapped points and connections into non wrapped form. For example you test which direction a point is closest from the city and then place it at that point for any algorithms. The results of this translation can be cached in the save file, and at most may need update every time the map is expanded, or every time the points change (possibly with time?).

As far as the local pathfinder is concerned, it just needs to get the convoy to the appropriate portal. Once at the portal, the convoy can be removed off the playable field and added to another system which deals with "off world" convoys. Such system would be nothing more than a timer queue where once the convoy reaches the portal it is added to the queue to arrive back at a certain time and with certain results. The advantage of such system is you could have potentially thousands of off world convoys and they would have practically no computational overhead.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #39 on: August 19, 2017, 03:03:53 PM »
Wrapping would be achieved for such algorithms by translating all wrapped points and connections into non wrapped form. For example you test which direction a point is closest from the city and then place it at that point for any algorithms. The results of this translation can be cached in the save file, and at most may need update every time the map is expanded, or every time the points change (possibly with time?).

Are you aware of any known algorithms that do this?

Quote
As far as the local pathfinder is concerned, it just needs to get the convoy to the appropriate portal. Once at the portal, the convoy can be removed off the playable field and added to another system which deals with "off world" convoys. Such system would be nothing more than a timer queue where once the convoy reaches the portal it is added to the queue to arrive back at a certain time and with certain results. The advantage of such system is you could have potentially thousands of off world convoys and they would have practically no computational overhead.

This is still assuming that we have actual portals, rather than convoys just leaving the map and carrying on. The difficulty with actual portals, as discussed above, is that choosing the appropriate portal is not easy. Do you think that having actual portals (rather than seamlessly integrated foreign destinations) would have a major advantage?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline DrSuperGood

Re: Portals
« Reply #40 on: August 19, 2017, 06:02:11 PM »
Quote
Are you aware of any known algorithms that do this?
I recall polar projection from primary school. Basically the map becomes the centre of view and all destinations are then translated to be around it. The nature of the projection is such that the real life distance is conserved during translation. This sort of projection is often used for aircraft routes since they need to be distance optimized for maximum economy, with deviations only for air hazards or weather effects such as using jet streams or avoiding storm fronts.

The projection wraps from the surface of a sphere into 2D with only lines of radius being distance correct and lines of circumference not being correct. As such it can be used for routes leaving the city, but the same projection result cannot be used for routes from 1 out of world place to another. For inter out of world routes one would have to create a separate projection for each and obtain the distances for valid routes as appropriate. Of course the projection only needs to be created involving potential destinations with regard to a single place and exist to generate the routing graph, after which the routing graph itself can be used and saved. Routing graphs would only be invalidated and need regeneration if changes occur to available out of world routes or their locations, so at most will be regenerated very seldom.

Quote
This is still assuming that we have actual portals, rather than convoys just leaving the map and carrying on. The difficulty with actual portals, as discussed above, is that choosing the appropriate portal is not easy. Do you think that having actual portals (rather than seamlessly integrated foreign destinations) would have a major advantage?
One could define an entire map edge to be a portal. For actual routes then one would use a separate algorithm with more than 16bit precision to compute the actual portal point, the point where the convoy will leave the world. Once the convoy reaches this portal point it is subject to portal mechanics and will eventually return at the portal point. Things like running cost and time of profit could be interpolated based on the out of world graph. The advantage of not having a convoy physically travel to the place is that one does not have to simulate movement and even running cost granularity can be lowered greatly reducing the computational overhead of the convoy. This would be very advantageous because one can potentially expect thousands of convoys being off world at a time as some trips might take in game years (think of the massive multiplayer server, the ships took 1-2 years to travel from one side of the map to the other and that represented ~800 km, hence thousands of ships were used).

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #41 on: August 19, 2017, 07:47:17 PM »
I recall polar projection from primary school. Basically the map becomes the centre of view and all destinations are then translated to be around it. The nature of the projection is such that the real life distance is conserved during translation. This sort of projection is often used for aircraft routes since they need to be distance optimized for maximum economy, with deviations only for air hazards or weather effects such as using jet streams or avoiding storm fronts.

The projection wraps from the surface of a sphere into 2D with only lines of radius being distance correct and lines of circumference not being correct. As such it can be used for routes leaving the city, but the same projection result cannot be used for routes from 1 out of world place to another. For inter out of world routes one would have to create a separate projection for each and obtain the distances for valid routes as appropriate. Of course the projection only needs to be created involving potential destinations with regard to a single place and exist to generate the routing graph, after which the routing graph itself can be used and saved. Routing graphs would only be invalidated and need regeneration if changes occur to available out of world routes or their locations, so at most will be regenerated very seldom.

Does polar projection work when the starting point is a sizeable area rather than a point?

Quote
One could define an entire map edge to be a portal. For actual routes then one would use a separate algorithm with more than 16bit precision to compute the actual portal point, the point where the convoy will leave the world. Once the convoy reaches this portal point it is subject to portal mechanics and will eventually return at the portal point. Things like running cost and time of profit could be interpolated based on the out of world graph. The advantage of not having a convoy physically travel to the place is that one does not have to simulate movement and even running cost granularity can be lowered greatly reducing the computational overhead of the convoy. This would be very advantageous because one can potentially expect thousands of convoys being off world at a time as some trips might take in game years (think of the massive multiplayer server, the ships took 1-2 years to travel from one side of the map to the other and that represented ~800 km, hence thousands of ships were used).

That is one way of doing it - but would that not involve some branching logic in the vehicle pathfinding algorithm? Perhaps I am not fully understanding: say one has a vehicle on tile 100,52 (in world), and it its destination is (imaginary) tile 200952,127359 (off-world). What steps would it go through to calculate to which map edge tile to fly/sail in your suggested model?

Thank you for your useful thoughts on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline zook2

Re: Portals
« Reply #42 on: August 19, 2017, 09:10:21 PM »
That is one way of doing it - but would that not involve some branching logic in the vehicle pathfinding algorithm? Perhaps I am not fully understanding: say one has a vehicle on tile 100,52 (in world), and it its destination is (imaginary) tile 200952,127359 (off-world). What steps would it go through to calculate to which map edge tile to fly/sail in your suggested model?

That sounds trivial for straight lines, i.e. aircraft. But what if it's a ship and the calculated edge tile is not water? Maybe the entire map edge is land, or water tiles not reachable from the ship's position. I guess the existing pathfinder could still route the ship through a different map edge, but I remember that very long paths are a problem.

I agree that portal-less travel is more elegant and (slightly) more correct in terms of distance, fuel use, range etc., but portals would avoid the above problem. They could also serve as GUI elements, e.g. clicking a portal could open a list of cities lying in that direction and the vehicles traveling there. Finally, I suppose moving through a binary city tree structure should use much less CPU/RAM.

Offline DrSuperGood

Re: Portals
« Reply #43 on: August 19, 2017, 10:19:10 PM »
Quote
Does polar projection work when the starting point is a sizeable area rather than a point?
Maybe from the centre of the map? If not then it can be done as part of the scheduler when caching a route to an off world city. The projection logic itself should be trivial cost as long as the results are cached.
Quote
What steps would it go through to calculate to which map edge tile to fly/sail in your suggested model?
Use polar projection at stop to find portal tile for route, and subtract that Euclidian distance from the total distance to stop, placing that into the portal logic and get convoy to move to portal tile. Once convoy reaches portal tile (similar to a normal stop point) then remove it from standard convoy update logic and place it into convoy portal logic system. Portal logic does off world stuff (flexible). Once it is time for convoy to come back into the world then it is removed from portal logic and placed back into convoy update logic with its pathfinding related stuff set to move from the portal point to its next stop.

As far as schedule goes, there would be automatically added portal points (which are like normal waypoints). When in the portal logic it advances the schedule appropriately until the re-entry portal point where the convoy is placed back into standard convoy update logic. If the automatically generated portal entry or exit waypoints are deleted all off world destinations they were involved with are also deleted. If an off world destination is deleted, then all portal way points are removed and recomputed resulting in new ones as appropriate. This schedule logic would allow one to have a convoy visit multiple off world locations and manipulate the schedule reliably. Off world logic for a convoy will not change if its assigned schedule changes, it will still arrive at its originally scheduled time however once it does then it will re compute its route and start the new schedule.

These are really rough ideas of how one could try to do it. There might be implementation problems and oversights.

As far as off world accuracy goes. As long as computed times are roughly correct it would be good enough and no one will notice the difference. This means that delays such as airport turn around times can be factored in as constant times, and that there are no deviations on flight paths and shipping routers. One could add a cost factor for routes that increases the effective off world distance travelled but does not increase the profit earned, this could apply to certain transport types such as ships to factor in having to go around obstacles. Off world mechanics do not need to be exact, they just need to feel good enough for an illusion of the convoy traveling to a far away place.

Online jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15828
  • Total likes: 405
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Portals
« Reply #44 on: August 20, 2017, 12:24:03 AM »
That sounds trivial for straight lines, i.e. aircraft. But what if it's a ship and the calculated edge tile is not water? Maybe the entire map edge is land, or water tiles not reachable from the ship's position. I guess the existing pathfinder could still route the ship through a different map edge, but I remember that very long paths are a problem.

The pathfinder would only need to do anything complicated within the game world for the ships - it could assume straight lines outside the game world (on the assumption that we cannot sensibly simulate things like the Cape of Good Hope and Cape Horn).

Quote
I agree that portal-less travel is more elegant and (slightly) more correct in terms of distance, fuel use, range etc., but portals would avoid the above problem. They could also serve as GUI elements, e.g. clicking a portal could open a list of cities lying in that direction and the vehicles traveling there. Finally, I suppose moving through a binary city tree structure should use much less CPU/RAM.

The trouble is that the original idea of portals also has intractable problems, as discussed above.


Quote from: Dr. Supergood
Maybe from the centre of the map? If not then it can be done as part of the scheduler when caching a route to an off world city. The projection logic itself should be trivial cost as long as the results are cached.

Vehicle routing is not cached - only passenger/mail/goods routing. Vehicle routes are calculated just before each convoy begins its journey.

Quote
Use polar projection at stop to find portal tile for route, and subtract that Euclidian distance from the total distance to stop, placing that into the portal logic and get convoy to move to portal tile. Once convoy reaches portal tile (similar to a normal stop point) then remove it from standard convoy update logic and place it into convoy portal logic system. Portal logic does off world stuff (flexible). Once it is time for convoy to come back into the world then it is removed from portal logic and placed back into convoy update logic with its pathfinding related stuff set to move from the portal point to its next stop.

Hmm - is the idea that it would first check to see whether the destination is in map or out of map and use a different pathfinding algorithm depending on the result of that check, one that, in the case of off-map destinations, used polar projection to find the appropriate portal point? That conceivably might work as the checks for on/off map would be infrequent enough not to affect CPU usage, although I am not quite sure how the actual pathfinding might work for off-map destinations.

Perhaps the schedule entries would have to be different for off-map destinations, and contain special 32-bit co-ordinates which could then be fed to an exit point finding algorithm?

Quote
As far as schedule goes, there would be automatically added portal points (which are like normal waypoints). When in the portal logic it advances the schedule appropriately until the re-entry portal point where the convoy is placed back into standard convoy update logic.

Ahh, is this how you imagining the caching working? I suppose that, in the case of a ship where the exit point had been turned into land, this could be discarded and recalculated? I wonder how one might deal with the case of unreachable portal exit points, e.g. a portal exit point for ships in a small inland lake?

Quote
If the automatically generated portal entry or exit waypoints are deleted all off world destinations they were involved with are also deleted. If an off world destination is deleted, then all portal way points are removed and recomputed resulting in new ones as appropriate. This schedule logic would allow one to have a convoy visit multiple off world locations and manipulate the schedule reliably. Off world logic for a convoy will not change if its assigned schedule changes, it will still arrive at its originally scheduled time however once it does then it will re compute its route and start the new schedule.

These are really rough ideas of how one could try to do it. There might be implementation problems and oversights.

Thank you for your thoughts on this: they are much appreciated. The ability for player vehicles to travel between different off-map destinations would be very worthwhile, as it would simulate the practice of having early aircraft calling at multiple points between origin and destination to refuel.

Quote
As far as off world accuracy goes. As long as computed times are roughly correct it would be good enough and no one will notice the difference. This means that delays such as airport turn around times can be factored in as constant times, and that there are no deviations on flight paths and shipping routers. One could add a cost factor for routes that increases the effective off world distance travelled but does not increase the profit earned, this could apply to certain transport types such as ships to factor in having to go around obstacles. Off world mechanics do not need to be exact, they just need to feel good enough for an illusion of the convoy traveling to a far away place.

The mechanics do need to be fairly exact, as all of the balancing data will be based on real life data, so things will not balance if things are too far out of line: but deviation from reality by a few percent will not matter greatly. How far off reality do you think that polar projection would be for an Earth sized world (max. straight line journey without getting closer to the starting point again ~ 20,000 km) with a map of 1,000 - 2,000 km square?

Thank you again for your thoughts in respect of this: this will be most useful when I eventually come to implement this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.