Started by jamespetts, May 14, 2017, 09:25:19 PM
0 Members and 1 Guest are viewing this topic.
Quote from: Yona-TYT on May 15, 2017, 12:53:10 AMI 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.
Quote from: VladkiWhich 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?
Quote from: jamespetts on May 14, 2017, 09:25:19 PM... (3) an alternative means of solving the basic problem,then I should be most interested in such ideas.
Quote from: Jando on May 19, 2017, 12:52:36 PMI 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.
Quote from: jamespetts on May 19, 2017, 01:03:33 PMThis is not really a solution to the basic problem so much as a means of giving up trying to find one.
Quote from: jamespetts on May 19, 2017, 01:03:33 PMSimulating 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)?
Quote from: jamespetts on May 19, 2017, 01:03:33 PMThere 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.
Quote from: Ves on June 02, 2017, 11:34:57 PMFor 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.
QuoteGUI-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.
QuoteI 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.
QuoteRegarding 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.
Quote from: jamespetts on June 03, 2017, 12:35:20 AMThank 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.
QuoteThe 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.
QuoteThat 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?
QuoteI am not sure that I fully understand how this would work or what you mean by this. Can you elaborate?
Quote from: laos on June 03, 2017, 07:17:52 AMRequire 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.
QuoteAdditionally, 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.
QuoteI 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
QuoteThe 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
QuoteI 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
QuoteOne 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.
QuoteAlso 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
Quote from: Ves on June 03, 2017, 09:32:17 AMThe 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!
QuoteIt 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.
QuoteI 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.
QuoteNot 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?
QuoteIf 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?
QuoteI 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.
QuoteI 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.
Quote from: jamespetts on June 03, 2017, 11:59:57 AMThis 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.
QuoteWould 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.
QuoteIndeed, 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).
QuoteYou 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.
QuoteIn 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.
QuoteEdit/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.
QuoteAnother 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.
QuoteOn 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.
QuoteGoods 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.
Quote from: Ves on June 03, 2017, 05:29:15 PMOne 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.
QuoteYes it might be better and easier to just assign speed for different eras and methods manually in simuconf.tab.
QuoteSounds 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.
QuoteExcellent, then I can practice a bit more
QuoteI 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?
QuoteAlthough 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.
QuoteThe 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.
QuoteI 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.
Quote from: jamespetts on June 03, 2017, 09:19:38 PMThe 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.
QuoteWhat do you mean by "more restrictions like connectivity"?
Quote from: Ves on June 04, 2017, 09:16:42 AMI 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.
QuoteHandling 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.
Quote from: Vladki on June 04, 2017, 06:47:19 PMUh 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.
QuoteIf 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.
Quote from: jamespetts on June 04, 2017, 10:09:08 AMOn 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.
QuoteThank 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.
Quote from: DrSuperGood on August 19, 2017, 02:56:52 PMWrapping 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?).
QuoteAs 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.
QuoteAre you aware of any known algorithms that do this?
QuoteThis 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?
Quote from: DrSuperGood on August 19, 2017, 06:02:11 PMI 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.
QuoteOne 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).
Quote from: jamespetts on August 19, 2017, 07:47:17 PMThat 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?
QuoteDoes polar projection work when the starting point is a sizeable area rather than a point?
QuoteWhat steps would it go through to calculate to which map edge tile to fly/sail in your suggested model?
Quote from: zook2 on August 19, 2017, 09:10:21 PMThat 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.
QuoteI 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.
Quote from: Dr. SupergoodMaybe 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.
QuoteUse 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.
QuoteAs 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.
QuoteIf 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.
QuoteAs 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.