Recent Posts

Pages: [1] 2 3 4 ... 10
2
Patches & Projects / Re: Convoi auto unbunching on line
« Last post by sebastien on Today at 08:17:38 PM »
Hello Train-catcher !

I tested your patch on pak128 / Windows. This is great! It works perfectly and the buses are well distributed throughout the line. Exactly what I was looking for.

However, it would be even better if it worked with bus stations (ie several bus stops with a choose signal). Currently the buses arriving at the same time leave at the same time.
3
Simutrans Extended Discussion / Re: Portals
« Last post by jamespetts on Today at 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.
4
Simutrans Extended Discussion / Re: Portals
« Last post by DrSuperGood on Today at 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).
5
Looks like there quite a bit of procedural coupling, similar statements are repeated with slightly different arguments. This is generally bad for maintainability and should be avoided when possible.
6
Okay, can you upload it please, it looks interesting. Also, I am building a new map similar to that.
7
Extension Requests / Re: Multiple Tiles Inner City Building
« Last post by Leartin on Today at 04:44:08 PM »
The cityrules does not force building next to a road. It is very easy to add a rule to fill holes or inner rows.

Sure, as I said...
Current rules tend to only allow buildings next to roads, even if spawning one tile further from the road is enabled, it usually has a way lower rate.
Plus, there is a reason why they are usually not covered by the cityrules - because nobody want's them to exist as single buildings.
8
Extension Requests / Re: Changing Buildings
« Last post by Leartin on Today at 04:36:51 PM »
That is a very eurocentric view. Most building here in Japan are rather considered worthless, when they reach 30 years of age. Just last month they cleared an old farm house near a river surrounded by cherryh trees to make place for a parking lot.

So there must be a threshold, i.e. the building must survive a certain time after their retirement date. Then it can be just make owned by the public player and then be protected as well.

If a building is not worth being refurbished, just don't create a refurbished version of it, and it won't ever refurbish. If that is the case for all japanese buildings, then pak.japan probably won't use that functionality. But since most paksets are eurocentric, most paksets could use it.
There does not need to be a threshold, at least not in the game code. The creator just needs to set the replacement date correctly. Sometimes, a replacement date equal to retirement date makes sense. For example, think of a parking spot with cars. The parking spot itself would not change much over time, but the cars would. It would not matter at all when the parking spot was buildt, when the time for different cars is reached, they change.

The protection thing is more of an afterthought to protect really old buildings. The straightforward way would probably be to have something like "no_upgrade_after=[date]", which could be implemented completely seperately from self-replacing buildings. But I have an issue with the idea of descriptions, and which tense to use. Descriptions about how this morning a wench stumbled over the chamber pot of the houselord wouldn't quite make sense if the building was still around in the 21 century.
9
I built an airport:



I also built some train lines to go with it:




10
[FR]Français (French) / Re: Chaines snfos (ubuntu)
« Last post by sebastien on Today at 04:26:55 PM »
Bonjour,

Dans ma partie, avec cet addon, j'ai bien une "Poulterer_Farm" qui produit Viande, Eggs et FoieGras ainsi qu'un "Wineyard" qui produit des "Grape". Il y a des vignes autour.

Quand tu dis que "les grappes de raisin et les œufs ne sont pas visibles", c'est qu'il n'y a pas ces biens dans la liste des biens (attention c'est Grape et Eggs qu'il faut chercher) ou c'est que tu n'as pas de fabriques pour ? Je crois qu'il est possible que certaines chaines ne soient pas entièrement disponibles sur une carte, en fonction des paramètres de création. Tu peux vérifier, en passant en service publique, la présence de la fabrique, en utilisant la fonction d'ajout manuel de fabrique.

Les .pak que tu devrais avoir en plus de ceux cités sont factory.Wineyard.pak et factory.Poulterer_Farm.pak.
Pages: [1] 2 3 4 ... 10